Secure, distributed hierarchical convergence network

ABSTRACT

A facility for performing employing multiple frequencies in a secure distributed hierarchical convergence network is described. The facility receives a signal in a first frequency, converts the received signal to an internal representation, applies a business rule to the converted signal, and, when the business rule indicates that the signal should be transmitted in a second frequency, causes the internal representation of the signal to be translated to a second frequency and transmitted in the second frequency.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a Continuation Application of U.S. Non-Provisionalapplication Ser. No. 14/886,704 filed on Oct. 19, 2015, published asU.S. Publication No. 2016/0143075, and entitled “SECURE, DISTRIBUTEDHIERARCHICAL CONVERGENCE NETWORK,” which issued to U.S. Pat. No.10,098,132 on Oct. 9, 2018, which is a Continuation-in-Part Applicationof U.S. Non-Provisional application Ser. No. 13/948,062, filed on Jul.22, 2013, published as U.S. Publication No. 2013/0308495, and entitled“SECURE, DISTRIBUTED HIERARCHICAL CONVERGENCE NETWORK,” which issued toU.S. Pat. No. 9,167,619 on Oct. 20, 2015, which is a Continuation ofU.S. Non-Provisional application Ser. No. 12/160,598, filed on Jul. 10,2008, and entitled “SECURE, DISTRIBUTED HIERARCHICAL CONVERGENCENETWORK,” which issued to U.S. Pat. No. 8,494,458 on Jul. 23, 2013, andwhich is a U.S. National Stage application of International ApplicationNo. PCT/US06/06471, filed on Feb. 23, 2006, and entitled “SECURE,DISTRIBUTED HIERARCHICAL CONVERGENCE NETWORK,” which claims the benefitof U.S. Provisional Patent Application Ser. No. 60/655,808, filed onFeb. 23, 2005, and entitled “Secure, Distributed HierarchicalConvergence Network,” the contents of which are all incorporated hereinby reference in their entireties.

BACKGROUND

In the land mobile radio (LMR) communication environment LMR networksconventionally use a single frequency range to transmit and receiveradio signals. There exist many types of LMR networks using manytransport and modulation schemes carrying different types of formattedinformation in the radio wave. The most basic are analog information andcurrently the most advanced are P25 & Tetra standards-based digitaltransmissions. LMR networks generally carry half duplex or multi channelduplex voice communications. Additionally, the digital based LMRnetworks are capable of carrying low bandwidth data.

Commercial wireless carrier networks use commercial frequency ranges tocarry full duplex voice and packet data. The U.S. military makes use ofother frequency areas in various low band and high band ranges carryinga variety of voice and data transmissions. The frequency ranges areseparate from the public safety, government and commercial ranges sothat the transmissions have minimal radio interference with each other.Additionally, multiple modulation schemes and transports exist betweenwireless carriers and vary greatly on military bands. Add to this thepublic broadband frequency allocations for 802.11 and other publiclyavailable spectrum areas and the spectrum chart break down is fragmentedin no particular order with a large number of incompatible modulationschemes and transports making it very difficult for specific voice anddata applications using separate frequencies and networks tointemperate, as is illustrated in FIG. 1. FIG. 1 further illustrates GSMwith SMS with full-duplex voice, UHF LMR analog with full channel voicewith no transport layer, 800 MHz LMR P25 with narrow band voice, andmilitary band for voice.

This stove piped frequency and transport arrangement has never beenideal but now there is an urgent need by the government and militarywith a compelling business case for commercial communication companiesto be able to interoperate and communicate between frequencies anddisparate networks using both existing and next generation equipment.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating the current communicationsenvironment.

FIG. 2 is a block diagram illustrating peering points between twonetworks.

FIG. 3 is a flow diagram illustrating a process flow for peering pointtransmission management.

FIG. 4 is a block diagram illustrating peering point bridging networks.

FIG. 5 is a block diagram illustrating a controlled interoperabilitymeshed peering network.

FIG. 6 is a block diagram illustrating non-controlled peering using1Pv6.

FIG. 7 is a block diagram illustrating a billing clearing house.

FIG. 8 is a block diagram illustrating a voice call between two users ina shared mesh or peer-to-peer environment.

FIG. 9 is a flow diagram illustrating offline transactional topeer-to-peer billing synchronization with a convergence billing account.

FIG. 10 is a block diagram illustrating reconciliation of billingactivity with two network types.

FIG. 11 is a block diagram illustrating improved functionality onsoftware defined radio.

FIG. 12 is a block diagram illustrating an example of talk groups overmultiple networks.

FIG. 13 is a block diagram illustrating an example of event scenecollection and playback.

FIG. 14-17 are block diagrams illustrating examples of priorityenforcement distribution in convergence networks at various levels ofcapacity utilization and in various embodiments.

FIG. 18 is a block diagram illustrating upper and lower edges of anetwork.

FIG. 19 is a data flow diagram illustrating flow of data when data frommultiple dispatch systems are correlated.

FIG. 20 is a block diagram illustrating a generalized dispatch store.

FIG. 21 is a block diagram illustrating link measurement between twonetwork nodes.

FIG. 22 is a block diagram illustrating distributed archival and chainof command.

FIG. 23 is a block diagram illustrating a multi-agency peer-to-peerbackbone.

FIG. 24 is a block diagram illustrating a policy management system.

FIG. 25 is a block diagram illustrating feedback induced by radio.

FIG. 26 is a block diagram illustrating feedback induced by environment.

FIG. 27 is a block diagram illustrating feedback induced by multipleusers in proximity.

FIG. 28 is a block diagram illustrating a multi-mixed conferencingenvironment.

FIG. 29 is a block diagram illustrating voice bridge loop removal.

FIG. 30 is a block diagram illustrating multi-medium broadcast andinteroperable text messaging.

FIG. 31 is a block diagram illustrating identity proxying andcentralized provisioning.

FIG. 32 is a block diagram illustrating use of a service provider and aservice charter to create a service.

FIG. 33 is a block diagram illustrating certificate issuance, such aswhen using RISP.

FIG. 34 is a block diagram illustrating a model for migrating towardconverged devices.

FIG. 35 is a block diagram illustrating a non-converged network legacyspectrum.

FIG. 36 is a block diagram illustrating a publication and subscriptionmodel employed by various embodiments.

FIG. 37 is a block diagram illustrating delegated off-line provisioning.

FIG. 38 is a block diagram illustrating legacy frequency billing.

DETAILED DESCRIPTION

A facility is described for unification of disparate networks anddevices into a secure, distributed, self-healing, peer-to-peer-stylesystem of systems and its associated provisioning, management,monitoring, and group communication schemes.

The facility provides an ability to “converge” existing radio, wirelesscarrier, broadband wireless, and satellite and terrestrial networkstogether for use with existing equipment and next generation equipmentto operate as a single scalable system or network with a controlledcommon environment for voice, video and data applications requires newmethodology and approaches. The facility further provides ways forcontrolled distributed peering, services abstraction, frequencymanagement, network monitoring and management, provisioning and grouppolicy enforcement are needed.

The underpinnings for converged networks is the inter-frequencymanagement system, the multi-peer methodology, transport and servicesabstraction process and the common policy and security systems thatdynamically controls the use and operation of the converged network.

Inter-Frequency Management

Inter-frequency management can be regarded as taking stove-piped orseparate frequency usage ranges and allowing networks of differentfrequencies to work together in a controlled way. Points that exist on anetwork that provide a frequency and network intersection perform atransport translation to convert information that is transmitted on onenetwork to conform with the transport format of another network. This isthe most basic form of “seaming” different frequencies and network typestogether. The following process can be added to the basic seaming methodto create a controlled converged environment in which the underlyingnetwork and frequency resources are managed to allow the convergednetwork to function as a single system.

Each peering point should be aware of and be able to translate andenforce the policy or operating rules of the converged network. Toaccomplish this a secure consistent policy management system is part ofthe design of the converged network and every peering point in thenetwork includes a method of translating and enforcing, to the extentpossible, the rules or charter set forth for the network and individualtransmissions. The peering point should be aware of the capacity,performance, and current load of both (can peer many networks at asingle point but two has the same requirements) the networks it peersincluding frequency usage, as is illustrated in FIG. 2.

As illustrated therein, the peering point receives transmission fromboth networks and depending on the policy rules performs a transporttranslation and an application translation so that the transmission andcommunication task continue through both systems. Because the peeringpoint has information for both networks pertaining to network capacity,frequency capacity, and activity, the peering point can throttle,prioritize, cache, and application abstract and sync to enforce thepolicy rules of the transmission streams being received, as isillustrated in FIG. 3.

FIG. 3 is a flow diagram illustrating a process flow for peering pointtransmission management. As is illustrated therein, the peering pointgoes through the following process:

-   -   0. A network subscriber 330 uses a service on network 300.    -   1. Peering point down converts 302 frequency of network 1 to        digital transmission form.    -   2. Peering point finds the transmission type through a match        lookup table 304    -   3. Peering point performs transport translation abstraction        process 306 to common transport format    -   4. Peering point finds information or application payload type        through a match look up table 308    -   5. Peering point performs information or application payload        translation and abstraction process 310    -   6. Policy rules are applied 312 to abstracted transport and        information data    -   7. Decision tree determines next step and interface criteria        with other network (314, 316, 318, 320, 322)    -   8. If passed, rules-test-abstracted information begins the        send-through to network 2 (301) process 318    -   9. Peering point performs retranslation process 324 from        abstracted information to network 2 specific information or        application format    -   10. Peering point performs retranslation 326 from common        transport format to network 2 specific transport    -   11. Peering point performs upconvert 328 from digital form to        network 2 frequency transmission    -   12. Network 2 provides services to network subscriber 332

The result of this process is that both networks' frequency utilization,network load, and application activity is managed by the peering pointand cross network transmissions are blended into the existing activityof each individual network. With the appropriate business rules inplace, frequency resource allocation can be managed as well asconsistent environment “convergence” applications such as abstractedvoice talk groups can be synchronized with the underlying networks'(refer to network 1 and 2 in FIG. 3) different transport and proprietarytalk group or plain push-to-talk technology including simple channelizedanalog voice.

FIG. 3 illustrates a process of transmission management received at oneend of the peering point, performing frequency down-convert to digital,transmission recognition phase, transport translation process,determining what type of information or application abstraction isrequired, enforcing business rule/policy decisions on the abstractedinformation, forking to show decision logic to pass the stream throughto another network or not, determining what type of informationretranslation is needed for sending through to the other network for theinformation, transmission retranslation process, and upconvert and outon the frequency of the other network.

FIG. 4 is a block diagram illustrating bridging networks using peeringpoints. The figure illustrates a peering point with four networks beingbridged or managed: a VHF analog network 402, a P.25 800 MHz network406, a GSM network 404, and an 802.11 network 408. Also shown is theprocess for dual network peering. The application and informationidentification indicating a voice call on the GSM or push to talk on theVHF analog on channel 7 is shown, along with a P.25 narrow band voicetalk group participating on P.25 800 MHz and a PDA push to talk on the802.11 network. For each one of these, the specific application orinformation translation has a type match for group voice. The figureillustrates an abstracted application translation to an inter-networkgroup voice application format. Also illustrated is the retranslationand sending out portion of FIG. 3, reversed from the first part of thisfigure.

As is illustrated in FIG. 4, the dual abstraction, charter based peeringpoint technique described herein is not only applicable to LMR networktypes, but also can be applied to wireless carrier, satellite,terrestrial backbone, public WiFi and peer-to-peer types of networks orany combination thereof.

Peering Point Management and Achieving Convergence Networking

By providing a consistent convergence networking environment through adually abstracted transport and application layer, a truly functionalconvergence network can be obtained. There are multiple methods throughwhich a consistent convergence layer can be achieved to make multiplepeering points behave in a consistent and synchronized way throughpolicy-based rule sets. One method is to have a central resource (e.g.,transaction) server or series of servers that can coordinate rule setvalidations and resource requests. A second method is to have apeer-to-peer or distributed methodology that enables each network orfrequency peering point to decide how to enforce the collectiveconvergence network policy so that the convergence network functions asa single network in a secure mesh topology, as is illustrated in FIG. 5.

Extending the power of the controlled peering into a consistentabstracted application is very powerful. The dual abstraction method forabstracting both the transport and the information or applicationpayload is important for creating controllability and scale forconvergence network applications to provide true country wide or globalinteroperability such as multi-frequency, inter-network group voice,push-to-talk, conferencing or talk group functionality as is illustratedin FIG. 5. This figure illustrates 20-50 mesh style policy-based peeringpoints similar to FIG. 4, but showing COMP riding on MPLS, indicatingthat network-wide requests, resource allocation and management is allcoordinated and in sync based on a consistent policy based rule setenforced at every peering point.

Without the ability for the peering point to manage the frequencyresources and control the underlying networks through rules set by thepolicy charter in addition to generalizing the information and tasksbeing transmitted to a common format large scale multi-frequency,inter-network interoperability may not be possible. Once multiplepeering points and hundreds of networks are seamed together withoutcoordinated control of the peering points and networks to operate as asingle converged network collisions, noise, over-capacity, latency andresource allocation request starving will occur. This type of unusablenetwork scenario will occur if, say, 100 to 500 peering points simplytranslated transport and payload between frequencies and networks suchas when using IP or IPv6 as the backbone between dual 100-500 peeringpoints. This is illustrated in FIG. 6. According to FIG. 6, 20-50 basicfrequency translation boxes are connected via IPv6 without policymanagement or knowledge of the overall network scheme or applicationabstraction. Also illustrated is how the collisions that non-controlledpeering would damage performance on all networks.

Economically Enforced Frequency Migration

One of the difficult problems in frequency management by NTIA and FCC ishow to migrate customers from one frequency range to another. Theproblem is that if frequency capacity is reached and a customer needs alarger spectrum range to handle the load, a new frequency is granted andthe new LMR network is installed using the new range. The old equipmentstill needs to be used for some time during the migration process. Whatcurrently happens is that the old frequency range and original LMRnetwork is used for extended periods because of coverage issues of thenew system and budget constraints that do not allow everyone to have anew device with adequate new infrastructure to cover a large enoughcoverage footprint. Therefore, frequency migration is potentially takingup twice the total spectrum allocation required, adding to thefragmentation problem and creating an environment where frequencyresources are becoming even scarcer. This problem is anticipated toincrease when national radio networks, such as the joint DHS, DOJ, andTreasury project for a national integrated wireless network, come online. A method for encouraging multi-frequency, multi-network usage isneeded along with a method for encouraging frequency migration to becompleted in a timely manner.

A method for economically enforcing frequency migration is an answer tothis problem. Using the multi-frequency, multi-network peering techniqueand convergence network control as described above provides a consistentway to measure frequency range usage by quantifying radio transmissionsin a way that calculates bandwidth utilization during the peeringpoint's dual abstraction process and provides a way to measure usage ina generalized method so that policy rule enforcement and a quantifiablebilling rate can be assessed for usage of the original frequency rangeover time. This makes it possible for controlling agencies to assess amigration time value based on a monetary agreement without disruptingthe operational use of communications on the original network. Hence, ifa customer wants to keep running their old system past the time agreedupon, a mechanism for charging a fee on a usage or activity basis can beenforced by the peering points depending on the usage and the policy.This should encourage migration or allow a quantifiable method forkeeping both spectrum allocations, as it can now be budget for totalcost of ownership. This provides an efficient mechanism for frequencymigration, as is illustrated in FIG. 34. FIG. 34 is a block diagramillustrating a model for migrating toward converged devices.

Inter-Agency Frequency Clearinghouse

To extend this one step further, it is now possible to define a newmethod of frequency allocation. Instead of providing bulk frequencyrange grants, controlling agencies can provide frequency ranges that areused by many different networks and customers (e.g., agencies). Theallocation of the range takes the form of bandwidth, utilizing thefrequency to bandwidth conversion as described above, and usage criteriathat is then utilized on demand. This frequency clearing house processallows networks and devices that have the proper identity and policycharter to pay for the bandwidth and its related frequency resourceusage on a prepaid, monthly, or per use basis. The result is a moreefficient method of spectrum allocation and resource usage. The pricefor usage can be set to a floating rate based on the availability ofresources and the usage criteria. An example of this is to allocate afrequency range that allows network peering points as described aboveand peer-to-peer devices that conform the security and policyrequirements of the above defined convergence network. A transactionalengine allowing credit card or digital payment mechanism can tie intothe different billing methods and a market rate can be set for spectrumusage of the same range by multiple networks and customers, as isillustrated in FIG. 7. According to FIG. 7, the clearing house 700 showsa conversion area for frequency to bandwidth, a policy generator andrevoking system 702, a billing system 704, and a transaction server 706.A car 709, a phone 710, a wireless camera node 712, and a Radio networkwith a peering point 714 (as described above) are all connected to theclearing house, such as wirelessly.

The process for multiple customer, floating rate, per usage sharedfrequency range is as follows:

-   -   1. A device that transmits on the shared frequency range is        loaded with peer-to-peer network layer 716 that supports        security model, policy model and the billing system described        herein.    -   2. A transactional system clears credit cards or digital        payments or employs a billing system.    -   3. The transaction or billing system 704 selects the amount of        bandwidth and the term that is anticipated to be used along with        the usage criteria such as priority level 708.    -   4. The transaction is executed.    -   5. A policy document 718 is generated and is distributably        stored in the network indicating the devices' network usage        privileges and usage allotment.    -   6. The billing system is interfaced for usage depending on usage        environment 720.    -   7. When the device has reached its usage level, the certificate        will be revoked 722 or none honored by the other devices,        networks and peering points in the network.    -   8. A customer can refill or make monthly payment to continue        usage.    -   9. Priority and other usage criteria are automatically enforced        during network usage 724.

Advanced Billing Systems and Techniques for Convergence Networks

New techniques and systems are required to monetize resource and taskcriteria-based usage of a converged network with the ability todetermine transmission or task type because the native billing meteringcontrol, usage tracking and consolidated accounting typically takesplace on the underlying network. The inclusion of the dual abstractionlayers and the ability to overlay an abstracted transport changes theability of the underlying billing system to necessarily tracktransmission type or application. Additionally, LMR and WiFi stylenetworks do not typically have any base billing system for aggregateresource or per transmission use metering. Furthermore, peer-to-peerbilling techniques may be required between devices sharing resources andthere may need to be a mechanism for billing state enforcement andsynchronization from devices and network segments that go on and offfrom the main convergence network or backbone.

In some embodiments, the facility provides a consistent billing systemthat can interface at the peer-to-peer node if the peer-to-peer network,billing, security and policy software is loaded onto the device or ifthe network or device is converged at a peering point, as is describedabove. The peering point in these embodiments provides a virtualidentity to users of the network and through a generalized dualabstraction layer process the facility can meter and control activity bycausing the policy rule sets to become a part of the consistent billingsystem. In addition a billing synchronizing mechanism is put in place todeal with peer-to-peer network state changes becoming isolated fromconsistent billing system servers and then being reconnected.

Offline Transactional Peer-to-Peer Billing

Offline transactional peer-to-peer billing is the process of metering,measuring and enforcing shared resources between peer-to-peer devicesand users in an adhoc environment with or without connectivity to theconvergence backbone where the consistent billing system servers reside.The technique for doing this is a secure distributed policy-based methodof resource sharing and network control. A resource sharing policy ruleset document is created for each device and user on the peer-to-peernetwork. The document specifies shared network usage criteria such aspriority and quality of service level. Additional specifications fornetwork and group permission as well as the billing base type (per bulkusage metering, per time metering, per task type metering) are alsoincluded in the billing policy document. Each device through thepeer-to-peer software has a cryptographic way of storing the network andtransmission activity of the device. Additionally, there is a debit andcredit system built in for usage swapping and each peer-to-peertransmission has a cryptographic currency that is exchanged betweendevices indicating the cost and bandwidth and transmission cost be usedby a communications task on a shared network. FIG. 8 provides an exampleof a voice call between two users in the shared mesh or peer-to-peerenvironment and how offline billing is conducted.

Flow of the offline transactional peer-to-peer billing process:

-   -   1. Each device has a peer-to-peer network security policy 802.    -   2. Additionally, each device has a billing charter document 804        indicating usage criteria of the shared network, the consumption        amount and how to account for and exchange usage.    -   3. The cryptographic currency that is exchanged between        peer-to-peer network participants is recorded in the secure        debit and credit section 806 of the currency system based on        each device's billing charter.    -   4. Depending on the rules of the charter each user could be        allowed to go negative or past the stated amount of bandwidth or        resource usage allocation indicated in the charter (808).        Alternatively, the charter rules could enforce no more usage by        the user (i.e.: no more calls could be made) but the device        could still be allowed to route shared traffic of the        peer-to-peer network.    -   5. The currency exchange process increases the credit section of        each transport node that is not part of the end-to-end        transmission which at this stage is sharing its resources to        those nodes that are using the node as a router, pass through or        repeater to send transmission to a particular node such as voice        (810).    -   6. Policy enforcement provides usage criteria that accompany the        transmission through the shared peer-to-peer network such as        priority and quality of service (812).

Once the peer-to-peer network segment or each node/device rejoins theconverged backbone network, the offline transactional peer-to-peerbilling process conducts a syncing process which updates the convergenceaccount of the user with the offline usage information. A cryptographicdebit and credit reconciliation process occurs between each device tosync the convergence consistent billing account with the devicesinternal debit and credit balance. At this stage the convergence billingaccount depending on the account status can replenish and modify thebilling charter document to reflect the business rules for that useraccount.

FIG. 9 illustrates a process for offline to online peer-to-peer billingsyncing to a consistent convergence billing account. The process occursas follows:

-   -   1. A reconnection state change notification is received from the        peer-to-peer network protocol (902).    -   2. The convergence billing system 904 performs a charter or        policy check and billing state check for billing sync        requirements (906). This check may be performed by another        component of the facility.    -   3. If at block 908 syncing is required, the process performs a        location look-up for convergence billing service.    -   4. At block 908, the process connects and authenticates to        billing server containing master account with billing properties        and activity logs.    -   5. The process initiates a syncing process to reconcile between        peer-to-peer node debit and credit levels with account activity        and usage (910).    -   6. At block 912, usage records the added to convergence billing        account of the node.    -   7. At block 914, a modified billing policy document is        generated.    -   8. At block 916, the modified billing policy document is        transmitted to the node.    -   9. At 918, the process causes the charter system to update debit        and credit.    -   10. At 920, the sync is completed, and the new billing and        charter policy state is ready.

Unified Multi-Carrier Billing

New billing techniques may be required to add wireless carrier networksto the convergence networks. To maximize coverage and redundancy of theconvergence network, the ability to add multiple wireless carriernetworks using different frequencies and underlying transports (GSM,GPRS, CDMA, 1×RTT, UTMS, iDen), with separate billing systems for bothvoice and data segments, into the consistent convergence network billingsystem is useful. The ability to reconstruct multi-path multi-networktask sessions and provide aggregate and individual account clearing andreconciliation for the underlying carrier network are new techniqueswhich can be used for seamless underlying wireless carrier toconvergence network provider interface.

Using a two carrier example case to explain the process, two carriernetworks converge onto the convergence network through themulti-frequency, multi-network peering technique described herein—twoseparate peering points. A multi-frequency device, say a PDA withGSM/GPRS and CDMA/1×RTT chipsets (separate, combined orsoftware-defined), can connect to one or both carrier networks to jointhe convergence network. The PDA has the peer-to-peer, security, andpolicy and billing software on it. The PDA then initiates a voice calland the policy rules indicate that Quality of Service (QoS) isparamount. The environment is such that the peer-to-peer protocoldetects that the GSM/GPRS network has a strong signal with low latencyand the COMA voice channel also has a strong signal. The policy ruleindicating a high level of QoS should be used if possible dictates tothe device that both networks should carry the voice traffic (see priorart for multiple circuit details). The GSM/GPRS circuit is running overthe data side of the network which is IP based and connects to theconvergence network via the peering point and then on to a push-to-talkgroup conference service. The second network constructs a circuitswitched data connection on the voice side of the network and goesthrough the peering point and connects to the same push-to-talk groupconference service. When transmissions are sent and received, thetransmissions are duplicated on both networks. Billing for theunderlying carrier networks is collected by each carrier's billingsystem independently and has no way to determine what the actualtransmission type or task was. All the underlying billing systems knowis that either a voice session that is time-based was initiated orpacket data was sent to the peering point.

The convergence billing system can collect and reconstruct amulti-network/transport call based on the initiating usage criteria.This can be collected at the peering point during the dual abstractionprocess or can be collected on the device itself because it is also apeer-to-peer node that interfaces with the convergence billing system.The billing policy and usage periodic updates from the peer-to-peertechnology are synced with the convergence billing system as describedabove. A total convergence network resource calculation can be done on atask or network basis and the syncing mechanism can record this activityin the convergence billing system account information for the user.

The peering points can also sync with the billing system because theyare also peer-to-peer nodes on the convergence network and record actualcarrier segment billing records for the task transmission as wellproviding a way to reconcile activity from two separate points on theconvergence network, the device and the peering point. From theserecords, a complete task can be recorded and reconstructed in theconvergence billing system indicating how much and what type oftransmission took place on the underlying carrier network.

A clearing house function can reconcile billing activity by account orin the aggregate with the underlying carrier billing systems based onthe business agreement with each. Then billing transaction records canbe sent to the carrier or from the carrier to the convergence providervia RADIUS servers for complete reconciliation or payment exchange. Thisis illustrated in FIG. 10.

According to FIG. 10, two carrier networks are connected to theconvergence backbone. A carrier 1002 is GSM/GPRS and the other 1004CDMA/1×RTT. A PDA 1006 is connected to both carrier networks, as shownwith dotted lines, which then continue through the convergence backbone1008 to the convergence push-to-talk server 1010, indicating adual-pathed high QoS push-to-talk converging session. From the peeringpoint icons of both carriers, a different line to the convergencebilling system shows a records sync. Another line type shows RADIUStransfers for reconciliation between the convergence billing server andeach carrier billing icon.

Legacy Frequency Billing

Usage of frequency is quantified by four metrics: Spectrum footprint,time, duration, and geographical footprint. Gathered together with adistilled version of the communication—speaker voice identification(voice print) metrics, frequency and volume envelopecharacteristics—these metrics form the Spectrum Activity Measurement(SAM). Because a single user activity (i.e. a single push-to-talkcommunication via handheld radio) may traverse several differentfrequencies in different geographical areas at different times (i.e. ina LMR network utilizing repeaters) a second metric, the Spectrum UsageMetric (SUM) is used to measure the total effect of that user activity.A single SUM includes several pieces of SAM data joined together torepresent the total spectrum resource usage of a single activity engagedin by a user. In conjunction with the metered usage price of therelevant spectrum, the SUM is used to calculate the monetary cost of auser activity.

There are several methods of gathering SAMs. These measurements may begathered from existing legacy infrastructure either by transmittingusage logs collected by existing radio infrastructure to be processed bythe billing system, installing new software on that infrastructure togather usage information, by attaching a new logging device to thatinfrastructure to gather the usage information. These measurements mayalso be collected by placing a radio receiver or several radio receiversin the relevant geographical area for the purposes of gatheringmeasurements. The collected measurements may then be transmitted to acollection point for processing.

To collect this data a hardware activity sensor using a standard LMRradio accessory connector (for example Motorola MaxTrac 5-pin analogaccessory connector or Kenwood 25-pin digital accessory connector) canbe used to extract and transmit activity information about the localradio network. This is achieved by monitoring the PTT indication sent bythe radio over the accessory connector and then retransmitting thatinformation via an out-of-band communications channel, for example amodem attached to a leased telephone line, or in-band encoded as data.

This device may be installed with a new radio base station as part of abilling infrastructure deployment or attached to an existing piece ofradio infrastructure. A number of modifications of this device may alsobe used to collect SAM data including a software approach where softwareor firmware performing the same function is installed on existingdevices, a software-defined radio combined with monitoring software isused to perform the same function, or a similar device utilizing aremote control interface (for example a tone remote interface overstandard telephone wire) is used to monitor an existing remote radio.

The software-integrated radio and software-defined radio approaches bothallow the collection of additional information about observed activitybeyond the defined SAM data. Additional data that may be collecteddepending on hardware configuration includes signal strengthinformation, audio quality information, and modulation type. PL tone,station identifier, or other transmitter identifying information mayalso be collected and transmitted with the SAM, aiding in assignment ofbilling.

Once the SAM data has been collected it is first checked for validity toexclude RF noise, stray signals from neighboring regions, and errantdevice behavior. There are several methods of evaluating whether acollected SAM is valid and should be transmitted for billing or whetherit should be discarded as invalid:

-   -   Audio quality evaluation    -   Signal strength evaluation    -   Neighbor spectrum check

For example evaluating the audio clarity of a received transmission (theaudio quality) will provide an indication of whether the signal wastransmitted by a transmitter in a region neighboring that beingmonitored. It will also indicate whether the transmission resembles abillable communication (e.g. a transmission on an analog LMR networkstrongly represents the acoustic characteristics of voice) or whetherthe transmission appears to be an environmental artifact (e.g. a burstof radio static from the starter in a vehicle). Signal strength may beused similarly, and verification of the physical proximity ofneighboring unowned transmitters allows the appropriate calibration.

To bill the correct entity for the measured usage for collected activitythe user initiating the activity should be identified. Several pieces ofinformation are available to aid in the user's identification:

-   -   Geographic region    -   Frequency used    -   Voice print    -   Relay access code    -   Prior notification    -   PL tone or station identifier    -   Other uniquely identifying handset characteristics

The combination of these pieces of information aid in the calculation ofthe billing entity to attribute the activity to. For example thecombination of the use by an agent of their fixed, agency-wide PL toneon a VHF handheld will allow that agency to be identified and thatactivity distinguished from activity generated by an agent of adifferent agency that uses a different PL tone. Another example of thecombination of this data is the combination of geographical informationand a relay access code, for instance the city the activity took placein and the access code used by an agent to activate their organization'srepeater.

Once a SAM has been attributed to a billing entity it should be sent toa legacy frequency billing service for aggregation into billable eventsand transmission to a unified convergence billing system. A singlebillable event is the collection of several SAMs to represent the totalcost associated with an action taken by a user, for example when a usertransmits voice on a legacy LMR network via a duplex repeater, thebillable event includes the spectrum time, physical footprint, andbandwidth usage of that user's PTT transmission across the originalfrequency used as well as the same measurements of the transmission madeon their behalf by the repeater. Another example of the combination oftwo SAMs that constitute a single billable event is the case of a singleradio transmission activity by a user that is broken by an intermittentbrief signal fade. The logging device may record this transmission astwo events SAMs when in fact the two represent a single user activity.There are several techniques that may be applied to combine a series ofSAM data into a single billing event:

-   -   Time correlation    -   Audio comparison    -   Repeater configuration verification

By comparing start and end times of two transmissions, any potentialrelationship between the two transmissions can be discerned, forexample:

-   -   Immediately adjacent end time of transmission A with the begin        time of transmission B indicates an interruption separating two        parts of the same transmission, given that other indicators such        as signal strength and user identifying information are        identical.    -   Immediately adjacent start and end times of both transmissions A        and B when A and B are geographically near and a repeater        bridging the two frequencies is present indicate the use of a        duplex repeater by the user initiating transmission A    -   Closely adjacent end time of transmission A with the begin time        of transmission B where A and B are on the same frequency but        have differing but internally consistent signal strength        indicate the use of a simplex repeater on one frequency

To confirm the accuracy of these comparisons a variety of additionalcomparisons can be made, primarily an audio comparison of thetransmissions to verify continuity (in the case of a brokentransmission) or similarity (in the case of a repeater duplicatedsignal). To make these comparisons some information about content shouldbe retained as part of the SAM.

The retention of this audio data in distilled digital format to allowverification and provide auditability is accomplished by way ofintegrating this data with the other recorded characteristics of theaudio in the form of the SAM. As discussed above speaker voiceidentification metrics as well as volume and frequency envelopes areretained as part of the SAM at time of collection. The SAM data may thenbe immediately transmitted to the legacy frequency billing service orretained on permanent or temporary storage on the hardware activitysensor for later scheduled or manual transmission. All data should betransmitted to the billing service in a timely manner to ensure thatcomplete data is available for the calculation of billable events. Thissystem is illustrated in FIG. 38.

Converged Frequency, Consistent Network Environment Devices

Technology has advanced to the point where a single device can containmultiple communication chipsets (each for a specific frequency range andtransport type) or a fast enough general processor functioning with abulk frequency range up-convert and down-convert chipset that can thentranslate the wave form segments into channelized specific transportforms. This is commonly called Software Defined Radio or SDR.

There are efficiency, coverage area and economic benefits that can begained from a device that can access multiple networks on multiplefrequencies. An example of this is the ability for a SDR based LMR radiothat can act as both a VHF or UHF device.

Network protocol technology advancements have also been made that cancreate a consistent network environment and super network of networks inlogically and physically distributed way. These technologies arecommonly referred to as Cryptographic Overlay Mesh Protocols (COMP) orpeer-to-peer adhoc protocols. These protocols generalize or abstract theunderlying transport of a native underlying networking to a commonlogical transport form. This makes devices and entire other networksfunction consistently together to create a unified convergence network.

A powerful new type of convergence device can be created by combiningthese two technologies so that the properties of the underlying networkand frequency is known to the peer-to-peer protocol layer anddocument-based network policies can be enforced in aggregate for all theunderlying frequencies and networks of the SDR or multiple chipset loweredge. This technique extends the ability for a device to just transmitand use different LMR, wireless carrier or WiFi networks in their nativeway to a generalized frequency and network management system that thedevice can use in a consistent way as a “resource pool” and applyabstracted applications that the underlying applications can betranslated to, allowing interoperable communications and inter-frequencyrange management to be performed in an efficient way. Additionally sucha device can act as a interoperable peering point similar to thatdescribed above so that single frequency devices that the lower edgesupports can be proxied or bridged onto the convergence network.Furthermore, this type of device can be used to help efficiently andeconomically move networks to other assigned frequency ranges. Dynamicfrequency consistent network environment device.

Adding a lower edge SDR and Upper edge peer-to-peer network protocolsuch as a COMP to the same device with a bidirectional multi-frequency,multi-network interface, a method is enabled for management of diversespectrum resources by abstracting multiple frequencies and modulationsto a consistent link layer and utilizing multi-path routing techniqueson the resulting links. Three new techniques are used to accomplish thisof converting devices to links, providing the upper edge a way ofmeasuring link quality metric of the underlying (lower edge) frequencyand network, and a collective aggregate link or resource policyenforcement management method. Additionally the device may need tosupport the security and policy engine functionality of the peeringpoint to act as a peering point for other legacy or single frequencynetwork device to join the convergence network.

The following describes a process of interoperable communications andinter-frequency range management with reference to FIG. 11:

-   -   1. A device's lower edge is made up of multiple underlying        network and frequency chipsets 1102 or SDR is utilized to        transmit and receive on multiple frequencies and networks.    -   2. The device's upper edge 1104 has a peer-to-peer COMP style        generalized communications protocol.    -   3. A bidirectional interface at the “Boundary Zone” 1106 allows        data, state, control information flow back between the edges.    -   4. The upper edge has the ability to poll each lower edge        chipset or SDR frequency range channel or network and receive a        link quality metric. For example: signal quality (1-10)*((max        capacity−current load)/max capacity).    -   5. The upper edge maintains an aggregate link resource state        which represents all the lower edge network resources.    -   6. The upper edge applies the resource policy based rules to the        overall resource pool and/or to each individual link state        depending on the rules to determine how to allocate the        resources to the tasks being run on the device.    -   7. The upper edge can use one or more of the underlying networks        to send or receive transmissions, which is determined by the        link states including the aggregate link state, the policy        rules, and the tasks being performed on the device.    -   8. The transmissions from each lower edge network go through the        dual abstraction process defined above allowing interoperability        at both the network and application level allowing the device to        utilize the aggregate network resource pool of the device as        interchangeable transports for common generalized applications        as defined above.

This provides the upper edge the ability to control the lower edgenetwork resources on a macro level depending on the convergence policymaking it possible to perform frequency and underlying networkmanagement for the device without disruption to the underlying networks.This is illustrated in FIG. 12.

FIG. 12 illustrates an example of push-to-talk talk group participationfor a multi-network lower edge device. An aggregate link resource poolis shown, with a high QoS policy with options for multipath routing overthe 802.11 (1202) and a P.25 lower edge (1204) through the convergencebackbone to the talk group service area on the network. Also shown is aVHF single frequency radio device 1206 acting as the bridge on the VHFlower edge interface of the device so that it too can get to the talkgroup service.

Convergence Resource, Network Capabilities and Performance Measurement

Convergence networking needs new metrics that quantify the performance,capabilities and resource usage on an inter-convergence and externalnetwork basis. This will aid in convergence network design and planningand allow rating of the new capabilities such as interoperability in astandardized way.

The process of measuring interoperability for a given network orgeographic area requires techniques for measuring frequency range usageand network resources in an abstracted way, determining the level ofinter-network connectivity, determining the amount of resource andapplication sharing and then quantifying the results into a singlerating with a set of corresponding ratios showing the current levelcompared to the max level of interoperability. The ratios provideinteroperability sub component measurements for frequencyinteroperability, network interoperability and resource and applicationinteroperability.

interoperability Metric

To compute interoperability, a consistent method of measuring resources,abstracting them to a common quantifiable measure and calculating theaggregate interoperability usage against the maximum potential usage ona given bounded range would be useful.

The technique for measuring frequency usage and LMR network resourceusage is defined in the legacy billing section of this document. Thiscollection method measures the usage of LMR networks through peeringpoints that can communicate on multiple frequency ranges and LMR networktypes. The transmissions then go through the transport abstractionprocess and the frequency use is converted to a common bandwidthmeasure. Devices and peering points function similarly for publicspectrum ranges such as 802.11 and for wireless carrier spectrum rangesand networks. By being able to effectively count the different LMRnetworks, wireless carrier networks, and broadband wireless networks fora given geographic range a quantifiable network and frequency range aWireless Underlying Convergence Network Count (“WUCNC”) is established.A terrestrial network count can be established by counting or detectingthe number of ISPs with nondependent backbones in the area, zero if noneexists in the range. This is called the Accessible Terrestrial NetworkCount (“ATNC”). Ranges that have satellite networks in operation (earthstation or receivable device) also have an Accessible Satellite NetworkCount (“ASNC”). By summing these counts together, a Total Network Count(“TNC”) is established for the given bounded range:

TNC=WUCNC+ATNC+ASNC

By performing trace routes on underlying networks and correlating theconvergence intersection points from the peering points a Convergencenetwork path (network intersection points), sometimes referred to asmulti link circuit construction, can be calculated to a MaximumContiguous Interoperable Network Count (“MCINC”) as well as aConvergence Network Fragmentation Count (“CNFC”) which represent thenumber of network segments that cannot communicate with each other.MCINC=CEILING (Contiguous Network Links)=Contiguous Network Count=numberof nodes in the largest connected component of the network. CNFC=Numberof isolated network components which cannot communicate with each other(e.g., the number of connected components in the graph theoretic sense).

Define the Connectivity Interoperable Rating (“CIR”) using theconnectivity values above to obtain a total connectivity score.

CIR=(TNC−MCINC)/TNC

The CNC is the number of networks in the largest fragment. The MCINCranges from 1 (which is the worst case, when no network may reach anyother network except itself) to NC (which is the best case, when eachnetwork can reach all NC networks, the total number of networks).

When MCINC=TNC then CIR=0 and CNFC=1 which means there is only 1“fragment,” i.e. all networks are interconnected. When MCINC=1, theneach network is in its own isolated fragment, i.e. it can reach onlyitself. In this case, CNFC=TNC and CIR=(TNC−1)/TNC−1 (approaches 1)which means the networks are increasingly isolated from each other.

By monitoring and calculating the bandwidth usage for each network andfrequency, a overall Range Network Usage Percentage (“RNUP”) can becalculated.

RNUP=AVG((Underlying Network & Frequency Bandwidth Max-UnderlyingNetwork & Frequency Bandwidth Usage)/Underlying Network & FrequencyBandwidth Max)

A total bandwidth usage may be computed as a weighted average across allnetworks. If the collection of networks is {N1, . . . , Nt}, then theweighted average may be calculated as:

${{Total}\mspace{14mu} {RNUP}} = {{{Weighted}\mspace{14mu} {Average}} = \frac{\sum\limits_{i = 1}^{t}{{{RNUP}\left( N_{i} \right)}*{N_{i}}}}{\sum\limits_{i = 1}^{t}{N_{i}}}}$

By performing the second abstraction process or application/informationabstraction at the peering point and calculating the percentage of data(in Megabytes) going to the abstracted or common applications versusdata just being passed through to the device or peering point, anApplication Interoperable Percentage (“AIP”) can be calculated on anetwork-wide basis. AIP=AVG(Underlying Network & Frequency AbstractedApplication & Service Data [Megs] To Common Applications andService−Total Abstracted Data Megs)/Total Abstracted Data [Megs])

Let AD(N)=Abstracted Data in network N. then:

${A\; I\; P} = {{{Weighted}\mspace{14mu} {Average}} = \frac{\sum\limits_{i = 1}^{t}{{{AD}\left( N_{i} \right)}*{N_{i}}}}{\sum\limits_{i = 1}^{t}{N_{i}}}}$

The basic measurements and quantifications now exist to provide anaggregate Total Interoperability Rating (“TIR”) by weighting thecalculations as follows:

TIR=(CIP+AIP)/2−(100%−RNUP)/10

The (100%−RNUP)/10 is a capacity usage weighting that is subtracted outof the AVG of the CIR and AIP combined. The purpose for this is tomagnify the excess capacity of the aggregate networks to encourageinteroperability technology and usage. For example if a bounded range isonly using 60% of the average aggregate network capacity there is 40%unused on the network that can allow for inter-network traffic. Ifaverage aggregate capacity is 100% the network usage is maxed so nothingis removed from the score.

Situational Awareness Metric

To compute situational awareness of an incident based on networkresource presence and usage, a consistent method of measuring resources,abstracting them to a common quantifiable measure and calculating theaggregate usage against the maximum potential usage on a given incidentbounded range is required. From these aggregate measure responders atthe scene can be given an individual situational awareness score forcomparison against the incident average. This can be calculated on realtime basis on scene or historically derived through reconstructing auditrecords (auditing is described in further detail below).

A count and abstracted rating of the network resources available at abounded scene is used to quantify a base network resource measure. Thisis accomplished through the discovery process (discovery is described infurther detail below). The number of responders, cameras, sensors,combined with a count of the networks on scene and the interoperabilityrating defined above are also used. These are base ingredients todetermine an awareness metric based on what communications occurred onscene.

-   -   TC=Total Cameras accessible on scene    -   TS=Total Sensors accessible on scene    -   TR=Total Responders (network users) on scene    -   TIR=Total interoperability Index    -   TCU=Total Camera Usage    -   TSU=Total Sensor Usage    -   TIT=Total Incident Time    -   ACPM=Average Communications Issued Per Minute

From these base metrics the next level abstracted measurements can bederived.

-   -   SVDT (Scene Visibility Device Total)=TC+TS    -   SVPR (Scene Visibility Device To Responder Ratio)=SVDT/TR    -   ATSVDU (Aggregate Total Scene Visibility Device Usage)=TCU+TSU    -   RSVDTA (Responder Scene Visibility Device Total Access)=Unique        (Responder User    -   ID for individual SVD device access)++ for All Responders on        Scene

A total incident awareness metric can now be quantified for the boundedincident scene.

-   -   TISSAR (Total Incident Scene Situational Awareness Rating) is a        weighted average of the following:    -   SVPR (Total SVD available Per Responder)    -   RSVDTA/TR (Percentage of Responders that accessed a SVD device)    -   ATSVDU/Total on scene network usage(% of usage for VSDs)    -   TIR*ACPM (total interop rating times A communication per minute        provides a weighting for Frequent communications where everyone        should receive—level of collaboration)

Individual usage per responder can be calculated and compared againstthe aggregate score. Similarly, incident scene scores can be compared tocome up with a best practices level.

Incident-Specific Aggregation

A process of aggregation so that all communications on the scene of anincident can be condensed into a single stream of information isprovided to aid in measuring on scene communication capabilities andusage. By utilizing the convergence network bounding method around thescene of an incident and the distributed auditing capabilities it ispossible to create a chronological sequence of communication events thatoccurred on the scene of an incident. An aggregate incident event streamcan be assembled by ordering the network user's transmission by identityand time stamp. Once this communications timeline and event assembly hasoccurred it is possible to provide a multi media playback of the sceneby using the transmissions generalized application and information typeID. This will allow a scene playback application that supports thegeneralized application format types to show video data, sensorreadings, group communications transmissions, cell phone calls, email,text messages, chats and the data entry of the on scene commander to thecommand and control log or application in actual event time. This isillustrated in FIG. 13.

FIG. 13 illustrates (1) event scene collection 1302 showing archiving ofcamera data, radio data, sensor data, and group talk group data; (2) asingle aggregate incident stream index 1304 in chronological order withtimestamps and task IDs pointing to specific transmissions withdifferent task or data IDs; and (3) a stream pulling tasks andmulti-media playback application 1306. The illustration showspoint-to-point playback with names on both sides, and a video playbackshowing one view of a scene.

Convergence Network Generalized Priority Management

Priority management of network resources is a desirable feature. Theability to distribute resources based on a priority level is animportant need for responders when responding to incidents anddisasters. Responders need their vital communications to get through onterrestrial networks, wireless carrier networks, satellite networks, LMRnetworks and peer-to-peer networks in times of crises. A few networkshave implemented priority service for responders on their networks suchas the National Communications System's priority program for voicecommunications on wireless carrier networks. The problem is that thereexist multiple priority mechanisms on different networks. There is noconsistency of priority between networks and no aggregate priorityenforcement. Also lacking is the ability to set multiple levels ofpriority on a per-user basis so that, for example, an incident scenecommander and firemen inside a building have a higher priority thanother responders on scene so that as resources become scarcer the mostimportant communications on the scene of an incident can get through. Aconsistent means of priority on an aggregate basis is desirable tomanage priority of voice, video and data transmissions on multiplenetworks.

A facility is provided for consistent priority on multiple networks andin the aggregate is now possible on a management, enforcement and usagebasis by leveraging the power of a peer-to-peer protocol such as a COMPand a convergence network environment with the ability to control theunderlying networks shared usage through a distributed policy basedmechanism. By supporting priority as part of the policy rule set andbeing able to interface with the underlying networks prioritycapabilities a powerful convergence aggregate priority and multi-networktask priority can be achieved.

Aggregate Inter-Network Priority

A method is described to enforce a consistent priority over multiplenetworks for voice, video and data is needed in a convergence networkenvironment. The ability for the network peering points to enforcepolicy based rules for underlying network and each peer-to-peer deviceon the network able to enforce the same policy it is possible to providea consistent priority level mechanism throughout the entire convergencenetwork by providing a generalized priority level rule in the policy.Each peering point and device can enforce the priority rule given thenetworks current load and capacity. This provides the desired effect ofallowing the network to function efficiently and only those areas of thenetwork that are at capacity need to implement the priority rule sets inaggregate for the load at the point only in the network.

FIG. 14 illustrates an example of priority enforcement distribution in aconvergence network. According to the figure, a convergence network 1402(wireless carrier, 802.11, LMR) with three peering points (1404, 1406,and 1408) and three devices using the generalized talk group service onthe backbone. The carrier network is reaching capacity saturation andallowing only the priority communications through. Only the carriersegment of the network is providing priority enforcement because therest of the networks have not faced maximum capacity.

FIG. 15 illustrates an example of multi-network consistent priority.According to the figure, all three networks are approaching capacity.The users of the talk group on all three networks can get throughbecause they each have a level 10 priority, while the others (e.g., the802.11 users watching videos) have lost capacity and resulting QoS. Adegradation of video occurs for the lower priority 802.11 users.

FIG. 16 illustrates an example of aggregate network consistent priority.According to the figure, WiFi users have a new convergence device 1602that can work over the carrier network and the LMR network. Other 802.11users on the network are accessing video. The policy of the powerfulWiFi convergence device user has a highest level of QoS rule. This poweruser is connecting to the generalized group talk services through allthree networks as a priority 10 user. The other users who are usingvideo have reached saturation on their networks. Each network aggregatepriority of the power user still allows the power user to use thehighest priority on each network, with slight degradation of video tothe other users on all networks.

FIG. 17 illustrates an example of enforcing multi-network,multi-priority level QoS. According to the figure, the WiFi network 1702is saturated with 10 users (nine computing devices and one cellulartelephone), each with different priority levels. The user with priority10 is connecting to the talk group server and getting through. The otherusers are watching video with only slight degradation. A user making acell phone call through the WiFi network gives up no bandwidth to theothers who are watching video. Another slight degradation to videooccurs as resources have been prioritized and shifted.

FIG. 18 illustrates an example of how a peer-to-peer device uses bestpriority carrier the network can offer. According to the figure, theupper edge and lower edge, similar to FIG. 16, where the policymanagement section shows high priority, and the lower edge using thebest priority that the underlying network can offer. The lower edge 1802is a GSM network with NCS priority capabilities. From a peer-to-peerCOMP device, the priority rule set causes the lower edge to activate anduse the priority capabilities of the underlying networks.

Through this process of generalizing a priority system that uses rulebased policy to enforce a consistent priority through the convergencenetwork and utilizing the priority capabilities of the underlyingnetworks based on that policy an aggregate prioritization can beestablished and enforced on a distributed basis throughout the network.

Convergence Network Generalized Services and Applications

It is conventionally difficult to determine whether coordinated attacksagainst America are occurring in timely manner. Today, the country'snews services are typically the fastest way to get information on anational basis about an incident—from powder found in a post office toAnthrax breakout to explosion. If an Anthrax breakout hits the localnews in LA, another one in Boston, and a third in Chicago, notice wouldbe taken that three separate geographic regions had a similar incident.At this point contemplation of coordinated attack would begin, as themalicious spread of a deadly disease would become a likely possibility.

Most incidents are logged or recorded by a responder group prior to thenews agencies showing up on scene. At the hospital it could be a recordof the symptoms at check in or at the time of ambulance pickup in theEMS dispatch log. A fire, chemical spill, explosion or armed standoff istypically recorded at an emergency dispatch center (e.g., 911 dispatch)or with dispatch at a specific responder department. There currentlyexists no standard way to share this information as these are typicallyseparate applications running on separate networks. This informationcould be automatically screened and analyzed for coordinated attackprobability on a nationwide basis by generalizing the incident ordispatch recorded information.

Shared Dispatch

A process is described for dispatch sharing so that information to bedisseminated in a timely manner between agencies and so that coordinatedattack analysis can be conducted on a geographic basis. A method isprovided for sharing and analyzing information to lead to the detectionof possible coordinated attacks and for inter-agency sharing of incidentand dispatch events. Through the converged network approach of dualabstraction it is possible to interconnect different networks in asecure manner and to also provide generalized services and applicationsthat can intemperate throughout the network. A Generalized dispatchapplication that utilizes the publication and subscription capabilitiesof a shared dispatch system can be created without the need forreplacing every dispatch system. By exporting and importing data andcommunicating on the secure convergence network to a generalizeddispatch service area and providing a thin translation layer between thenative dispatch system and the generalized dispatch record format,dispatch records can be shared using existing systems. This feature isillustrated in FIG. 19.

According to the figure, several dispatch systems 1902 are connected toa convergence network 1904. Also shown is convergence networkconnectivity to the network that the native dispatch systems areconnected to, along with the convergence backbone 1906 and thegeneralized service area 1908. XML based translation 1910 is performedand records are then published to the dispatch system. Records from oneof the others can show up in another native dispatch system viasubscriptions. Also shown is the process of subscription andretranslation (1912, 1914, 1916, 1918, and 1920) from the generalizeddispatch event to the native dispatch systems format. Although arrowsare shown for clarity, one skilled in the art will recognize that datawould flow both ways. As an example, data would flow from one of thedispatch systems through the convergence network to the general dispatchafter XML translation. The data could then be retranslated and providedto the other dispatch systems via subscription.

Once a generalized dispatch store exists, automated analysis, crosscorrelation of incident records can be performed and groups of eventsthat fall in similar categories of interests can be measured ondifferent time groupings to help determine if a coordinated attack isoccurring and over what timeframe. This feature is illustrated in FIG.20.

According to the figure, a generalized dispatch store 2002 runs groupingand analysis scripts for anthrax breakouts within the last 2 weeks anddetermines that an alert 2004 is required indicating three eventsrelating to LA, Boston, and Chicago. Also shown is an automated tickerpublication 2006 request broadcast nationwide, with a threat level tagof elevated, saying “Be on the lookout for Anthrax breakouts!”

Network Peering

Since the advent of inter-networking and particularly since the UnitedStates Government decision to break a large network carrier intomultiple corporations, it has become useful to connect pieces ofnetworking equipment owned by multiple parties. This process is referredto as “peering.” Connecting networks is complex from either party'sperspective since the other party could easily cause malfunctions,overuse the shared connection, or unfairly delay or discard messagesdestined for third peering parties.

Internet service providers (ISPs) set up peering points—the physicallocations where exchanges happen—and negotiate peering agreements (whichare essentially legal contracts setting out the exact details of howtraffic is to be exchanged). Most peering points are located inco-location centers, where the different network operators “co-locate”their points of presence.

In today's mobile, ad hoc networks, this arrangement can be too unwieldyto be effective. The entire duration of interaction between two devicescan be a few minutes or even as short as several seconds. In thisenvironment, there is not sufficient time to negotiate, write andexchange signed contracts among device owners.

An apparatus is provided for exchanging desirable peeringcharacteristics, negotiating a common peering agreement, exchangingdigitally signed documents intended to serve as an audit trail, andverifying that performance complies with existing signed documents.

Quantifying Underlying Transport Characteristics

To perform these features each machine should be able to measure theperformance of a communication channel and of remote channels asadvertised by other machines. Rather than relying upon a human todescribe the state and functionality of a network, the apparatus employsa feature by which each network element can learn and communicate thesecharacteristics. This feature is illustrated in FIG. 21.

To measure a communication channel between one machine and another, theparties execute the following protocol for some or all messagesexchanged between them.

-   -   1. The sender, “Alice” for the purpose of discussion, records a        temporarily unique message identification number into a memory        table, inserts the identifier number into the message, and        records the time at which it transmits the message. This is        referred to as a transmission record.    -   2. The recipient, “Bob”, records each incoming message        identifier and the time at which the message arrived into a        queue of unacknowledged messages.    -   3. At the next time Bob has a message to send to Alice, he        retrieves one or more entries from the unacknowledged message        queue and calculates the number of milliseconds passed since he        received the matching message, also known as the hold time of        each message.    -   4. In addition to executing this protocol symmetrically as the        sender of a new message, Bob appends the retrieved message        numbers and their respective hold times to the outbound message.        These are referred to as message acknowledgements.    -   5. Upon receipt of the new message from Bob, and in addition to        executing this protocol from step 2 as the recipient, Alice        retrieves the entries from the transmission record as indicated        by the message acknowledgements. For each, Alice calculates the        difference between the transmission time and current time,        called the round trip time, and then subtracts the hold time to        calculate the observed channel delay.    -   6. Upon receiving a message acknowledgement out of order from        the transmission record, Alice records all skipped entries as        dropped messages.    -   7. Alice then records the size of each message and the observed        channel delay, or that it dropped, in order to calculate the        total observed bandwidth, total observed loss, and typical        channel delay over a period.

With this information, each party on the network can automaticallyunderstand the media by which they connect. Using the calculationsperformed, it becomes trivial for each node to communicate the localnetwork structure to more or less distant peers. Because there is nohuman interaction, the system responds rapidly to changes duringcatastrophic events.

Load Redistribution Using Predictive Risk Analysis

Joining Disparate Backbone Links Together

When constructing a large network with multiple owners, each withmultiple sites, message routing policies should be exchanged andenforced according to the various constraints, such as those mentionedearlier. Rather than induce inefficiency and bottlenecks by connectingthe large number of sites to a central peering point, the facilityemploys a routing system based upon a cryptographic overlay meshprotocol.

The facility connects each site to two or more backbone orpoint-to-point communication channels and installs a mesh networkingprotocol node at each site. This seamless redundant backbone appears asa single, fully connected network whose routing characteristics followthe natural and political boundaries between the multiple owners.

To create this effect the facility installs a network router at eachsite, including connecting each available backbone or peer-to-peerchannel to the router. Each router then executes the following process.

-   -   1. According to the process described in Quantifying Underlying        Transport Characteristics, measure and record performance        characteristics of each link.    -   2. Each time a message is sent across a particular link,        calculate the difference between bandwidth used and observed        capacity.    -   3. Periodically (e.g., once per minute in some embodiments),        select a number of links capable of reaching each recently        requested destination. Make that selection such that the        observed capacity of the aggregate selected links is larger than        the highest recently sent message volume.    -   4. If during a given hour, the selection process in step 3        allocates more than a specified margin (e.g., 75% in some        embodiments) of the total capacity, issue a warning to request        human intervention.    -   5. Configure a cryptographic mesh overlay routing protocol to        use the selected collection of links.

Due to the dynamic nature of such a protocol, the bandwidth will comeonline transparently, making the network appear to have on-demandbackbone capacity just in excess of the required utility. FIG. 23provides an illustration of a multi-agency peer-to-peer backbone.

Creating Machine-Enforceable Resource Usage Policies

By using network-portable service agreements, the facility can securelyexchange machine-readable files to describe shared resources and thestrategy by which they are to be allocated. FIG. 24 is a block diagramillustrating a policy management system.

In some embodiments, the facility creates three tiers of allocation:

-   -   1. Allocate as much as 5% of a given resource on demand to any        recognized entity, allowing for fault tolerance when specialized        resources cease to function.    -   2. Of the remaining resource available, allocate as much as 30%        on demand to any entity with credentials deriving from the same        authority responsible for the resource, allowing for general        load distribution inside an organization.    -   3. Of the remaining resource available, allocate up to 100% to        any entity with a credential created specifically for the        resource.

Verifying Intra-Organizational Quality of Service

Using the link measurement technology described in QuantifyingUnderlying Transport Characteristics, an organization can understand thecapacity and performance of its internal network and its external links.However, it generally cannot measure performance outside that area.

Using a cryptographic overlay mesh routing protocol gives us the abilityto trust that when a node chooses to send messages through the network,intermediary nodes are unable to decipher the content. Thus, it ispossible for a node at the perimeter of an organization's network totest the enforcement of quality of service measurements advertised fromremote areas.

To measure the quality of service, a given node executes the followingprocess.

-   -   1. Collect a list of network identities observed during name        resolution and other sundry network processes. Ignore all        identities whose credentials derive from the same authority that        owns this network node.    -   2. Select a random element from the list and initiate a        voice-quality circuit with a single bit indicator set to inform        the target to echo every communication with the same priority as        a packet of voice data.    -   3. Query the network routing layer to retrieve the expected        performance to the selected remote node.    -   4. Choose a random arrangement of 128 zero and one values to        represent a number that is very difficult to guess.    -   5. Using the circuit created, transmit packet data matching the        profile of three seconds worth of voice data. In each packet,        fill the area reserved for voice data with the output of a        one-way hashing function over the string formed by concatenation        of the random number selected above with a zero-based counter.        This way, the remote node cannot forge the return packets to        bolster the apparent quality of service.    -   6. For each message received from the circuit, measure the total        round trip time to calculate network latency and record the        value in a list.    -   7. Once the entire test series is complete, find the worst        latency in the list and compare it to the advertised        expectation. If the observed latency is greater than the        advertised value, record the service violation for human        intervention.

Network-Portable Authentication of Administrative CommandsHierarchically Validating Resource Charter

After receiving an administrative command document, a node may need toensure that the security credentials of the creator are sufficient. Theadministrative command process is an application of the network-portableservice agreements and their associated policy process.

In this way, individual nodes can validate and authenticateadministrative commands without respect to the method of transmissionused. See FIG. 22.

Distribution of Administrative Commands

To communicate commands rapidly throughout a complex and self formingnetwork, multiple transmission schemes need to be created and managed.Executing the following process creates a blend of broadcast andnarrowcast channels for this purpose. See FIG. 24.

-   -   1. Create a list of network elements that need periodic        administration.    -   2. Create a series of categories of those networks elements so        that each category represents one likely target grouping for        administrative commands. Be sure to include a category for all        elements, in case the list of categories proves to be        incomplete.    -   3. Create and distribute a network-portable service agreement        for each listed network element, and sign it with a credential        recognized by all those devices.    -   4. At each network node so configured, execute the process to        join a naming ring for each category containing that node. In        this way, each device is addressable via each configured        category.    -   5. For each command to be distributed, create a network-portable        service agreement with a specified list of recipients and the        command to execute, and then sign it with an appropriate        administrative credential.    -   6. Mechanically compare the list of recipients to the list of        available transmission categories, and select the category with        every listed recipient and the fewest listed non-recipients.    -   7. Execute the naming ring broadcast process to send the command        document to each node.    -   8. At each node, execute the process described in        Network-Portable Authentication of Administrative Commands.    -   9. Search for the node's identity in the list of recipients. If        the name is not in the list, discard the command. Otherwise,        execute the administrative command as requested.

Efficient Public Safety Conferencing

In recent years, providing efficient communications during an emergencyhas become an important problem facing responders around the world. Mostexisting group communications options are heavily dependent oncentralized infrastructure to distribute voice data to the necessaryparties.

Radios conventionally require high-powered repeaters to extend a channelto any meaningful distance. Most modern radio systems also rely on atrunking controller that resides in a single location. Telephonyconferences require telecom infrastructure and a centralized location tomix audio streams and redistribute them to the calling parties.

The centralization of resources necessary for communication betweenemergency personnel means that communication could easily be disruptedor disabled by an attack on any necessary infrastructure component.

In emergency situations, auditing conversations at some later date isoften desirable. Traditional conferences can be recorded and audited atlater points. Even a hypothetical peer-to-peer distributed conferencecould be recorded in its entirety and audited later. However, manydevices participating in an emergency conference with no infrastructurewould not have the ability to record an entire conversation.

In normal operating conditions centralizing the conferencing and mixingservices can be desirable and does provide several advantages: easierload balancing, support for more participants, large amounts of storagefor audits and recordings, etc.

Conferencing solutions that induce any amount of latency between theorigin and destination of any audio data are can potentially create afeedback loop with the system providing the mixing services. This canhappen in a number of different scenarios (see FIGS. 22-24). In thesescenarios, the feedback loop is created because the audio is emitted atan endpoint later than it is produced at the mixing source, this allowsa device to pick up the product and send it back into the mixing devicewhere it will be redistributed to the endpoint devices and potentiallyfed back into the mixing device. The feedback will continue adinfinitum, or, more likely until it is attenuated to an indiscerniblestate.

Traditionally this issue is not dealt with because telecom conferencingis not subject to feedback owing to extremely small delay (any feedbackis attenuated extremely quickly) or efficient client device design(placement of microphones such that audio emitted from the speakerreaches the microphone with little or no energy). Traditionalteleconferences assume that none of the devices in the conference willbe in auditory range of each other.

A facility is provided that enables several methods that together allowconferencing to take place in emergency environments that lack aspecific infrastructure. It also provides mechanisms to improve theefficiency of centralized conferencing solutions for public safetynetworks. Several methods are described to avoid inducing any feedbackloops in conferencing systems. Various techniques are applied to eitheranticipate the feedback and mitigate it or to stop it from occurring bypreventing devices from emitting audio into other devices. The facilityalso describes several methods that allow for conferencing deviceswithout a centralized mixing mechanism. A method for associating everyaudio stream with a strong identity is described along with a method forprioritizing communication across the channel is described. The facilityenables several mechanisms that allow a group communications channel toboth emulate and extend capabilities similar to that of a traditionalhalf-duplex radio system. The system provides all the componentsnecessary for an effective emergency group communications mechanism. SeeFIGS. 22-25 and 29.

An individual may at any time be in possession of multiple devicescapable of communicating in one talk group (e.g., one person may have aP25 radio and a next-generation digital/converged communications device,such as a voice communications capable PDA). Each of these devices mayhave different latency characteristics as well as different talkactivation mechanisms. For instance, a PDA may be activated by voicedetection and a radio may be activated by pressing a PTT button. If theradio were to output voice data prior to the PDA, the PDA might detect avoice signal and retransmit it into a mixing application. This wouldimmediately cause a feedback loop. (See FIG. 22.)

This scenario can be prevented by associating each of the users deviceswith the user himself. The network or mixing application can thenrealize that a user has multiple devices active on a givencommunications channel and transmit it only to the optimal one. Theoptimal device would be determined by provisioning each device with apriority level. The priority level information would be shared with themixing device. The mixing device could then output a voice stream toonly the highest priority device, preventing a feedback loop from beingcreated.

A feedback loop could alternately be induced by one individual with onedevice that is operating in full-duplex mode. Voice communications couldbe emitted from the device and the resulting audio could echo off thesurrounding environment and be picked up by the full-duplex device'smicrophone (see FIG. 23). A poorly designed device may also simply pickup audio directly off the output device (i.e. speaker.)

This can be prevented by executing any number of widely available echocancellation algorithms on the endpoint. The algorithm would recognizethat the device had recently emitted a given audio stream and prevent itfrom being reintroduced into the system. Echo cancellation is explicitlydesigned to prevent feedback loops in any kind of voice communication.The facility prevents compounding feedback loops in an environment withmultiple simultaneous devices.

Multiple devices in auditory proximity where one device is transmittingand any other device is receiving audio data could easily induce afeedback loop by picking up voice from a nearby device (with differinglatency characteristics) and reintroducing it into the mixing device(see FIG. 24).

Echo cancellation algorithms with an extended window (at least the sizeof the maximal round trip latency of the most latent device on thechannel) implemented at the mixing device would effectively prevent anypreviously transmitted audio from being reintroduced into the channel.This would eliminate any potential feedback loop from being introducedinto the channel.

In many situations the participants in a conference, especially a VOIPconference, will have drastically variant latencies. The round-trip time(RTT) from one device to another may vary greatly from the RTT to acentralized mixing location. There are two ways to mitigate this andimprove response time. One is to use a peer-to-peer conferencingsolution as described below. Another way is to split the mixingresponsibilities up across a few mixing devices and then combine thedata at a centralized location.

Splitting the mixing responsibility allows all of the benefits of asingle mixing location with the added benefit of reduced latency betweenclose devices and the ability to combine conference arbitrarily withoutredirecting all of the participants. Mixing devices can easily combinestreams of audio and output a product. The product could be sent toanother mixing device that mixes streams from mixers. This chain can becompounded to an arbitrary depth with an increasing latency penalty foreach level (see FIG. 25).

Latency can be reduced in the following situation: Assume a number ofdevices take input from a land mobile radio system and convert it into adigital form that are grouped in two groups of five, one group on thewest coast and one on the east coast. The cross country latency is muchhigher than the latency from each of the radio bridging devices insideeach group (which are physically connected to each other via an Ethernetswitch). Response time can be improved for the local radio conference byplacing mixers locally on the east coast and the west coast andattaching the radios to the closest mixing device. The west coast couldthen connect its mixer to the east coast to provide a nationwideconference. Each of the local devices will be able to communicate muchmore rapidly because they are limited only by the local latency, not thenetwork-wide latency.

In a conferencing scheme with multiple participants and multipledevices, it is often desirable to allow each participant to use thecodec of their choice so that they can make optimal usage of theresources available to them. This means that the audio stream may beencoded multiple times, once for each endpoint. An equivalency class isa group of endpoints that all share common encoding properties. By onlyencoding the outbound data once for each equivalency class the amount ofwork done by the mixing device can be reduced.

In an emergency situation centralized mixing equipment may not beavailable. To still provide effective group communications, audio needsto be distributed to each party and mixed at the endpoints. Multicastingallows one chunk of data be addressed to many recipients. An intelligentnetwork that supports multicast will only split the data into multiplecopies when it is necessary. This means that one device couldpotentially broadcast voice to hundreds of recipients even if the deviceonly has enough upstream bandwidth to send data for one or twoconversations. In this system each participant transmits data over amulticast link to every other participant only when the participant isactively speaking.

To support the need for auditing, prioritization, and greatersituational awareness a method is provided for attaching an identity toeach audio packet as it is sent to a remote endpoint. In the system,each participant gives a key to an asymmetric cipher to every otherparticipant along with an identification. Before a participant sends anyaudio data he encrypts the audio data with his side of the key pair andattaches his name. This allows the remote side to locate the correctdecryption key quickly (via the attached name) and to verify the originof the transmission (e.g., by testing for a successful decrypt).

If multiple data packets are received from different source for a giventime span, each device mixes the data together before playing it out.This effectively distributes the work of mixing the audio data acrossthe network and allows multiple actively speaking participants.

To ensure that high profile individuals have communications precedence,a pre-negotiated priority is attached to each such individual. This canbe accomplished by distributing keys out of band and associating eachone with a name and priority. Other mechanisms could be used tonegotiate priority. Assuming each packet arrives with some way toassociate it with a priority level, the packet is associated with amoment in time (e.g., using RTP). If more than a preset n number ofpackets is received for a given time, all packets are ignored but thehighest n priority packets and only those are mixed.

The feedback prevention mechanisms can easily be applied to apeer-to-peer conference as described above. Wherever the methods forfeedback prevention mention the ‘mixing device’, or ‘mixer’, simplyexecute the algorithms on every node in the conference, as each one isconsidered a mixing device.

It may be desirable to set up a system whereby only a limited number ofparties may talk at once. This provides us with a more clearcommunications channel (and one that is potentially free of any feedbackproblems.) The notion of traditional radio PTT as ‘right-to-talk’ isabstracted. In a given communications channel, based on policy, some Nparties may at a given point in time be able to acquire theright-to-talk. The right to talk is acquired by transactionallyrequesting the right to talk from every device in the network. This mayfail if a traditional radio system is presently receiving data, or theradio system may choose to transmit anyway. Once every device hasregistered and verified (by executing the channel right-to-talk policy)the requesting parties right-to-talk, they update their state andcontinue. Once a party has acquired the right to talk, mixing deviceswill allow input from the device to proceed through the mixer and beoutput to the network (this works for peer-to-peer as well ascentralized conferences.)

If two parties ever attempt to acquire the right-to-talk (RTT)simultaneously, the channel's RTT policy is executed and the competingparties are assigned a priority. If the number of people trying toacquire RTT is below what the channel's limits are, then permission isgranted to all parties. Otherwise the remaining RTT slots are filled inpriority order.

The algorithm can be modified to allow for priority override if RTT isallowed to be revoked once it has been established. The prioritycomparison and RTT slot assignment should simply be done for both therequesting parties and the active parties. If a requesting party has ahigher priority than a party that already has RTT, that party may loseRTT depending on how many slots are available.

The policy may be executed before checking for available slots becauseit would be valid for the policy to increase the number of slots.

Infrastructure Free Cooperative and Emergency Resource Allocation andDiscovery

A party desiring to allocate resources in a network conventionallyrequests someone to allocate the resource, and may need to provide proofof various facts, such as permission. Additionally, whatever processdetermines which resource to allocate needs to know which resources areavailable to allocate.

Automatic discovery of computing resources available for use in an areawould be advantageous if made available to public safety personnel in avariety of situations.

In an emergency, the needs of local public safety officers may exceedtheir available resources. While the idea of surrendering bandwidth orother network resources to the police in the event of an emergency isnot often considered, it could easily become a real situation in theevent of a large terrorist attack or natural disaster. The inventors areunaware of real mechanisms for law enforcement personnel to effectivelysurrender bandwidth even if it were needed.

A facility is provided that defines a service charter as acryptographically verifiable autonomous digital document that describesa service that some machine will have the knowledge to create. Thefacility provides a method whereby machines capable of creating servicesregister themselves with a machine capable of assigning them work. Thiswork-assigning machine is discoverable by other machines on the network.The facility provides a system that allows for the discovery ofresources in geographic proximity to a location as well as the abilityfor public safety personnel to commandeer private resources for use inan emergency.

To allow service and resource agreements to be fulfilled on a globalscale without the need for centralized infrastructure, the concept of a“service charter” is introduced. The facility assumes that every userhas a cryptographically strong identity that can be used to associatethe user with various rights. The facility also assumes that all serviceproviders have policies that tell them whose service requests can befulfilled.

A service charter necessarily includes enough information to reconstructa service and carries all the information necessary to authorize thecreation of the service. It is in a sense “service currency.” A servicecharter should include the name, type, and access rights of the servicebeing described. It should be signed by whomever's resources are to beused to create the service, e.g., Joe acting on behalf of Corp X (Joehas a document signed by Corp X giving him the right to createconferences on the behalf of Corp X.) It would also include anexpiration time for using the charter to create a service. It mayinclude other arbitrary policy elements (such as delegation to aresource provider for re-issuing the charter). This document may provideproof that Corp X wants to allocate resources for a given service on thenetwork somewhere. This proof is entirely portable and may not requireJoe or Corp X's actual presence on the network, only the ability toverify their signatures. By including a complete signing chain and thepublic keys used to sign, any verifier only needs to store a hash ofCorp X's public key in order to successfully verify the certificate.

The use of the service charter requires knowledge of a service providercapable of creating the service described by the charter. The facilityuses a distributed hash map that contains a list of providers that arecapable of creating the desired service and a list of service providersthat will provide service to a given organization.

In large networks, picking which service provider to talk to in a waythat utilizes resources efficiently would be difficult. To address this,the facility adds a “service allocator” mapping to the hash map. It mapsan identity and service pair to a well defined machine. This machinekeeps track of all the available service providers for the givenidentity/service pair. It tracks which services are currently runningand where they are running at. This allows the service allocator to useany of a number of available resource allocation algorithms to makedeterminations about where services should be created. Exactly whichnode functions as the service allocator is decided by using an electionbased algorithm for all machines capable of serving as such. If thenetwork ever gets split into smaller segments, each segment will electits own service allocator for each service/identity pair.

The node would look up the servers capable of creating and the serverswilling to create it, take the intersection of the two lists, and thenhand the charter to a well-defined service allocator from the list. Theallocator will either create the service and tell the node where toreach the service, or if it already exists, simply tell the node whereto locate the service (see FIG. 32). The service provider asked toprovide the service would then double check to make sure it wasn'tduplicating a service, and proceed to activate the service.

The service charter, because of its portability, allows a service to becreated separately on any two completely disjointed networks. Becausethe mechanism allows an existing service to be discovered on a networkwhere it exists, and to be created on a network where it does not, itcan be ensured that a given service remains available in the event of atotal network separation. The only additional step required to ensurethis is to provide each user of a service with a copy of the originalcharter.

Now that services can be located based on type, the capabilities of thenetwork can be extended by adding a table to the hash map that is keyedbased on location and stores a list of service providers. In order toeffectively use the new geographic location information the facilityadds a new kind of service allocator for a special type of servicereferred to as the “location” service. This location service allocatoris looked up like any other service allocator. It requires a charterthat specifies geographic closeness to a location. The location serviceallocator will then return a machine-readable document (it may fetch itfrom other machines actually running a location service) that describesservice types that are available to the requester that match thegeographic search criteria.

To locate more general types of services, such as a camera or a heatsensor in close proximity, the facility creates another entry in thehash map which associates network wide agreed upon names, like “camera”and “temperature sensor,” with a list of specific service types thatfulfill the desired operation. If a node needs to find the more generaltype of service, the node simply requests that type in his locationsearch charter.

In an emergency, the police or other public safety personnel may have agreat need for network resource in excess of what is usually availableto them. To address this, a mechanism is provided that would allowpolice to temporarily take control of available network resources.

This is done by creating a new commandeering service. Any partyoperating on the network may be required to operate a commandeeringservice. This service will only accept charters from valid lawenforcement agencies. The charter contains the name of a service type orthe identity of a specific service provider that will be reassigned tothe requesting party for the length of time listed in the charter.

The results of such a request are completely auditable, so enforcementcan be handled offline through the legal system. An organization with aneed for a resource that could not be commandeered could simply not obeyany commandeering requests directed at it, or the commandeering servicecould refuse to honor the requests. Provided the organization hadobtained prior permission from the relevant government entity to deny acommandeering request, it would be immune from prosecution or fines.

A given agency may require services of a type not available to it inclose enough proximity to where they need the services, or at all. Thecommandeering service charter can include a desired service type. If thecommandeering service cannot locate an adequate resource, it forces anode to offer a service type that it is not presently offering, providedit has the physical and software components necessary to fulfill therequest.

After the service charter expires, a commandeered node would revert toits former state as it remembered it. The commandeering service couldalso store state from commandeered devices not capable of storing theirown state. This effectively restores the network to the desired stateafter the emergency is over. A charter could also be issued by theoriginal commandeering party revoking the commandeering order.

Global Revocation Management

Public key cryptography has been in use for many years in many differentenvironments. Public Key Infrastructure (PKI) is a term that is used todescribe systems that manage key provisioning, distribution, andrevocation of keys. Key revocation is one of the most technicallydifficult problems involved in the creation of an efficient PKI system.

A key revocation can be necessary for many different reasons. Once acertificate authority (CA) has decided that it needs to revoke acertificate, it will need to use whatever mechanism their PKI supports.CAs would ideally be able to invalidate any use of the desiredcertificate instantaneously and on a global scale.

There are essentially two mechanisms for handling revocation that are inwide use in PKI systems today. They both involve creating lists ofcertificates. A white list contains a list of all valid certificates. Ablack list contains a list of all invalid certificates. Many systemsexist to distribute and these lists, each with its own drawbacks andstrengths.

In general white lists are good for systems with a low number ofcertificates and black lists are generally better for larger systemsthat don't anticipate a frequent need to revoke certificates. In anenvironment where there are a very large number of certificates with apotential need to revoke a huge number of them, e.g. a secure meshnetwork, there are no good existing solutions.

There are a few other mechanisms to enact revocation, but they are notas widely used. These mechanisms include creating certificates with ashort validity period (thus requiring all clients to frequently refreshtheir certificates.) This method in particular is not often used becauseit has very high traffic and administrative overhead.

A facility provides methods whereby a CRL can be compressed to a verysmall amount of information that can easily be shared and validated byany part of the PKI. This is illustrated in FIG. 33.

Efficient CRL exchange is achieved by making a few observations andusing them to create an alternate notion of a white list. It could beviewed as isomorphic to a traditional white list that has beencompressed to one number.

First, a CRL enables a given node that trusts a particular CA to verifythat a certificate the CA signed is still valid. White lists provide asigned list of certificates that are valid. A black list contains asigned list of invalid certificates.

Each CA will issue each certificate with an edition number. This numberis monotonically increasing and is incremented when the CA decides toissue a new edition of its signed certificates. (See FIG. 34.)

A CA would initially issue every certificate with an edition of ‘0’. ‘0’would then be considered the CA's present edition. In this system acertificate is valid only if it bears an edition number equal to theCA's present edition.

In a situation where a CA had issued 20 certificates with an edition of‘0’ and then decides it is necessary to revoke 5 of them, it wouldproceed as follows:

-   -   1. Resign all certificates it wishes to continue to be valid        with an edition of ‘1’.    -   2. Make the certificates available to the necessary nodes.    -   3. Increment his present ‘edition’ number to ‘1’.

It is important to note that each of the clients of the CA, if they arethemselves CAs, do not need to resign their child nodes certificates,they only need to provide them with the up to date copy of their ownsigned certificate.

When a third party needs to validate a given certificate, it only needascertain the current edition of the CA that issued the certificate. Thewhite list of a given CA is thus compressed to one number—its editionnumber.

This method has several other useful properties. In the event one wereunable to or simply found it undesirable to contact the CA to ask forits current edition, a node could determine the current edition (or atleast get close to the most current edition) by tracking the currentedition for every CA that it encounters. If a node ever communicateswith a node that has proof of a more up to date edition for a given CA,the node can simply update its record of that CA's edition, without theneed to contact the CA. This method may not always produce the correctanswer, but it will be closer to being correct than having no ideawhether a certificate is valid.

This scheme also allows for very effective propagation of revocation.When a CA issues a new edition, each of its directly signed nodes couldbe contacted and given the new certificate directly. This is aninefficient part. If the CA was a root level CA or otherwise quite highin a trust hierarchy, there may be hundreds of thousands of nodes thatneed to be notified of the changes. Only a small portion of these willbe direct children of the CA.

Once the direct children of the CA have been updated, any node thatcommunicates with the children can simply copy the new certificate blockfrom the child. More generally:

-   -   1. Node A has an old edition of a certificate at the second        level of a 7-level certificate chain proving his identity.    -   2. Node B has a copy of the correct edition.    -   3. If Node A attempts to communicate with Node B, Node B can        simply give Node A a copy of the certificate with the correct        edition.

This method then limits the amount of traffic on the network due to arevocation (change of edition) to close to the lower limit of what ispossible. It also allows the information to be propagated on a need toknow basis, preventing massive traffic floods of nodes asking for newCRLs.

The certificates can be exchanged securely in this system without theneed to contact the issuer provided each node keeps track of a hash ofevery CA's public key along with its edition. Any node can then look atthe new certificate and verify its signature via the following process:

-   -   1. Ensure the complete public key is attached to the        certificate.    -   2. Hash the public key and verify that it matches your record of        it.    -   3. Verify the signature using the attached key.    -   4. Update its edition I certificate chain if the signature is        valid.

The methods described above provide dynamism and low resourceconsumption to provide an effective global scale certificate revocationscheme that is suitable for ad-hoc networks.

Efficient Aggregation and Dissemination of Messages

In many large organizations, there are many available platforms on whichto notify the members of the organization of an important event. Theimportance of notifications is magnified in the public safety sector. Inan emergency the difference between two minutes and five minutes for thedelivery of crucial information could be fatal. The manner of deliveryis also very important, an email is not going to help two policemen on abike route gain any situational awareness. Likewise a loud radio alarmwith a message converted from text to speech is not going to be a veryeffective day to day mechanism of reaching the governor.

A facility is provided for individuals and groups to publish a messagein any format and have it be delivered to another group or individual inthe best format for any individual that the message reaches. See FIG.30.

Individuals and groups can publish their notification policies onto thenetwork as well as the capabilities of their communication devices. Theydo so by putting the information in a network wide distributed hashtable. Each person is associated with a unique cryptographic identity.The hash of the public portion of this identity is used as a key intothe hash table.

Any communications device on the data dissemination network knows how totranslate a message in its native format into a standard messageinterchange format. For example, an email client may be able totranslate an email into a standard XML document and a radio bridged ontothe network may have the ability to translate speech into text and storeit in the same standard XML format. Likewise, any device participatingon the network may be able to render the standard XML format in itsnative format, e.g. a radio bridge may be able to convert the text in astandard XML format into speech. This ensures that any device on thenetwork can both transmit and receive a message.

Every party on the network should have a stored policy documentdescribing how to notify the party in different circumstances. The partyshould also have a communications configuration that maps to the policy,i.e., if the party has both a radio and an email notification device,their policy should spell out when to reach them via voice and when toreach them via text; the communications configuration document shoulddescribe the capabilities of each device the party is carrying and apriority number if the party is carrying multiple device capable ofnotification in the same manner. When a message is sent into the networkthe same policy document describes what characteristics should beattached to the message, e.g., ‘Urgent’. When deciding which device todeliver the message to for a given recipient, the policy is consultedand a unique result is obtained. The message is then routed to thatdevice and rendered into the correct format based on the receiver'spolicy.

Some devices may have multiple users associated with them, for example,a standard VHF radio may have approximately 50 officers on the samechannel. The communications configuration document describes how manypeople might be reached for a given rendering format. The same wouldapply for mailing lists. When a device successfully renders a message itreports back to the sender on how many people were reached and, if therendering device is capable or confirming receipt, whether or notmessage receipt was confirmed. The sender can then view a recipient byrecipient confirmation list as well as aggregate information aboutmessage delivery.

Centralized P25 Provisioning

The P25 radio standard is a standard for digital radio communicationthat allows radio handsets to be addressed individually in a debatablysecure fashion. Problems are encountered when one wishes to use theadvanced (for the field of land mobile radios) feature set of P25 radiosin a modern secure digital converged communications environment.

A facility is provided that enables a centralized service to provisionP25 radio systems with IDs that translate onto modern secure networksand how those networks can then be used to manage the devices. See FIG.31.

Using a standard public key infrastructure system a certificateauthority can issue a certificate to a proxy for a given radio systemthat allows the proxy to issue certificates for individual radios.Whenever a new radio is brought online its unique P25 identifier isassociated with a new public/private key pair by the proxy service. Theproxy service has awareness of all the P25 radios it has provisioned andall of their identities. Various proxy servers can aggregate thisinformation to a centralized data store. The proxy answers networktraffic destined to any of the P25 identities it is proxying for.Whomever controls the centralized data collection point can then addressany of the radios over the computer network in a cryptographicallysecure manner.

The proxy can provide a standard interface to the P25 system itadministers. Using network policy various configuration commands can beexecuted on the radio network based on preprogrammed events or throughdirect control by a party with appropriate access rights.

Network-Portable Secure Document

Security of transmission of a document is generally divided into fourattributes: privacy, integrity, authenticity, and non-repudiation.Depending on the application in question, each of these attributes maybe required for the transmission of a document to considered fullysecure. For example, in the case of a secure financial transaction allaspects are required for every message transmitted: knowledge of thedetails of the transaction should be limited to the involved parties,the integrity of each part of the transaction should be ensured, theauthenticity of each part of the transaction-particularly the identitiesand financial stats—is correct and not falsified, and it should beensured that the identity and authorization of the involved parties isattached in a way that withstands later questioning. In a second case ofa public announcement or alert that should be verifiable by anyrecipient even in the absence of any direct contact by the author andrecipient, integrity, authenticity, and non-repudiation are importantbut privacy is not. That difference in requirements allows an importantnew method of handling public secure documents.

Conventional solutions to these problems use public key cryptography ina process that requires access to central infrastructure, particularlyfor the non-repudiation portion of the process. Conventional solutionsalso provide for the secure transmission between one party and anotherbut provide no mechanism by which that message may be forwarded to athird party while retaining all of its security properties. Alternatesolutions that do not require centralized infrastructure will enablemany new applications, particularly those that involve heavy use ofcryptography to secure message transmission and that require thesemessages to be stored and retransmitted as availability of resources andnetwork status change.

By packaging the full signer certificate chain with a document, thedocument may be made verifiable by the receiving party without anyfurther communication. The advantages in doing this are twofold: notonly may the receiver verify the signatures on the document withoutfurther communication, the receiver may at a later time redistributethat document to any number of other parties without losing any of thesecurity properties of the document. That is, even the document'srecipient several transmissions removed will still be able to verify themessage's authenticity, the message author's identity, and the identityof every signer of the message author's identity all the way back to theroot certificate.

To mitigate the bandwidth and computational resource requirements inthis process, some of the cryptographic properties of a documentconstructed this way can be taken advantage of to allow differentialtransmission of signing information and full verification of identitywithout verifying every signature in the document. These optimizationsare possible without impacting the security of the process.

For the purposes of this description data that has the requiredproperties of verifiable authenticity, offline-verifiable authenticity(non-repudiation), and verifiable identity of the author will be calleda “network-portable secure document,” The process of construction,transmission, and verification of one of these documents is describedbelow.

Construction

To construct a network-portable secure document the data to be includedas the body is prepended with an identity certificate identifying andauthenticating the originator and the originator's signing key. Acryptographically strong hash of the document including the originator'scertificate (HMAC) is then appended to the document and the resultsigned with the originator's signing key the same key mentioned in theiridentity certificate-using standard public key techniques. The actualfull content of the originator's key is then appended to the message.This key should be either the root key of the PKI hierarchy, signed bythe root key of the hierarchy, or have a signer whose signature chaincan be eventually traced to the root key of the hierarchy. In the firstcase, the originator's key is sufficient. In the second, the root key isthen appended to the end of the collection of keys to be included. Inthe third case, not only is the originator's key appended and thesigning key for their certificate, but also each higher certificate inthe hierarchy required to verify that the chain of signatures reachesall the way to the originator of the message. This collection of datarepresents the entirety of a network-portable secure document.

Transmission

Once the document has been constructed in this way, naïve transmissionrequires only that the complete document be transferred to therecipient. Because the document contains all data required for therecipient to verify the document's authenticity based on the signatureof the trusted root key this transmission may include arbitrary time anddistance and over transmit-only mediums without affecting theverifiability of the document on receipt.

If a two-way medium is available for transfer of the document, it ispossible to optimize the transmission based on the shared certificatebase common between the transmitter and receiver. At transfer time thetransmitter need only transmit identifying information for the keysattached to the document in order from the originator's key to the rootkey, one at a time, until a common key is found. No further keys mayneed to be transmitted as the remaining signing hierarchy may then bededuced to be already stored in the receiving party's keychain. Fortransmissions between organizationally close parties this optimizationalong with the ability to verify only the newly received certificateswill allow a great reduction in the amount of data transmitted and thenumber of certificate verification operations executed.

Verification

Upon receipt of the document the recipient first checks that the HMACembedded in the document and the computed HMAC of the relevant portionof the document (author's certificate and data) are identical and thatthe digital signature attached to that portion of the document is validand was generated by the key indicated in the identity certificateembedded in the document. This process verifies that the contents of thedocument are unaltered from the time of creation and that the documentis certified authentic by the owner of the key indicated inside thedocument.

Given that it is verified that the document is internally consistent, aremaining task is to verify that the signing key indicated by theattached identity certificate and the identity specified within thatcertificate are authentic. This is accomplished by examining thecertificate chain attached to the document to verify that thecertificate used to sign the document is ultimately indirectly signed bythe root key, that is to verify that there is a continuous series ofcertificates beginning with the signer of the document and ending withthe root key in which each certificate is signed by the next one in theseries with the exception of the root key which is implicitly trusted.

Secure Network-Portable Aggregation

In a typical public-key cryptography application special authorizationand full trust is required to publish “trusted data.” In this casetrusted information is data that will be used by other participants inthe same PKI infrastructure and thus will have its signature checked forvalidity prior to taking any action based on the contents. In effectthere are only two classes of entities in this system, trusted anduntrusted, and only the trusted individuals may publish trustedinformation.

There are two key drawbacks to this approach. The first is that there isno means of validating that a trusted individual is operating correctlyto generate the trusted data even when that trusted individual is merelyoperating on other trusted data to produce its output. The second isthat even those operations that are mechanical functions of trusted datasourced from outside trusted sources require execution within a trustedentity in order to be able to publish a trusted result. The consequenceof these two drawbacks is that in the absence of trusted entities withthe ability to publish trusted data no trusted data may be published atall. This leads to a failure case in which a collection of entities whoare isolated from all trusted entities will no longer have the abilityto publish trusted data among themselves, even when such data may bemechanically generated.

A common way for an untrusted party to perform computations in averifiable way on trusted data to produce new pieces of trusted datawill enable more new applications to be built, for example distributeddecision making and notification tools for emergency communication.

A process is provided that enables an untrusted party to performvalidated computations in a verifiable way on trusted data to producenew trusted data. This is accomplished by building a mechanism thatallows data tied back to a specific computation and for the specifics ofthat computation to be verified, not just the identity of the persondoing the computation.

One new application enabled by this process is automatic tracking of thenumber of first responders on an incident scene. Rather than requireevery responder's device to update every other responder's device withits status when it comes on-scene, each responder's device simplylocates the highest on-scene authority and sends its identifyinginformation to that authority. That authority may then initiatenotification messages based on an increasing number of on-sceneresponders and attach sufficient authenticating documentation to thatnotification for any recipients to be able to verify the validity of thealert without consulting other parties on the network.

This process is particularly useful when portions of the network maylose connectivity and become isolated from any standard source ofauthority. In this case even an entity without typically sufficientprivileges may collect data and broadcast alerts based on that data aslong as the source data is signed and the decision-making criteria arewell-known. This provides a path of graceful degradation from optimaloperation with all resources and authorities on-line to suboptimaloperation with few resources available and no valid authorities on-linewith minimal disruption to the availability of data aggregation andnotification services.

The secure network-portable aggregation process is based on three keyconcepts: the secure network-portable document, aggregation, the trustedentity, and the verifiable process. The secure network portabledocument, described in detail below, is a portable format fortransmitting information with cryptographically verifiable integrity andauthenticity. Aggregation is the process of collection several pieces ofdata and performing a computation on them to produce a new piece ofresult data. A trusted entity is an entity that is authorized to performa certain function, in this context described by what data they have therights to sign. For example a surveillance camera may have the right touse its cryptographic key to sign video captures along with attached GPScoordinates of the camera but not any other type of data or any data notmarked with the same GPS coordinates (e.g., it cannot sign an e-mail oran image from a location where the camera is not). A verifiable processis a computing operation that is described in a mechanically executableway and is signed by a trusted entity. A signed Java executable is anexample of a potential implementation of this component. These conceptsallow construction of secure network-portable aggregation.

Construction

To produce a secure network-portable aggregation of data a strictprocess should be followed:

-   -   1. Source data signed by trusted entities is gathered by the        aggregator    -   2. The aggregator verifies the authenticity of the source data        by performing the appropriate signature checks and signer        identity verification as described elsewhere.    -   3. Verifiable processes signed by trusted entities are executed        and the resulting output data is collected.    -   4. For each piece of output data that will be published create a        new network-portable secure document containing the data and the        aggregator's signing key.    -   5. All data necessary to transmit the signed aggregated data is        now ready for transmission. At this stage the aggregated data        may be evaluated to determine whether it needs to be transmitted        to other hosts on the network for notification purposes.

Transmission

Transmission of the aggregated data is accomplished in a similar mannerto the transmission of a secure network-portable document. Similar tothe Network-Portable Secure Document (NPSD), the actual transmissionincludes not just the core portion of the document itself but also allindirect signing information including the full signature chain of theaggregator, the verifiable process document containing the process usedto do the aggregation computation, all source documents used in thecomputation, and all signing hierarchies back to the root key for eachpiece of source data and the verifiable process document.

Once all of this data is collected it may be transmitted without furthernegotiation to any other device or entity on the network. To reduce thenumber of certificates that should be transferred the transmitter andreceiver may determine what certificates, verifiable policies, andpieces of source data are already held in common and transmit only themissing difference.

Verification

Upon receipt of the aggregated data and all associated validatinginformation the receiver's should first validate that the data is valid.In the base case where the only common information or trust between thetransmitter and receiver is the root key's certificate all attached datawill need to be verified.

-   -   1. The authenticity and integrity of the data is verified, as        for any network portable digital document.    -   2. The authenticity and integrity of the attached verifiable        process is verified.    -   3. The authenticity and integrity of the attached source data is        verified.    -   4. The verifiable process is executed with the attached source        data as input and the output is verified to be identical to the        aggregated data.

While intensive, this process serves only as the baseline means ofverifying the aggregated data. The receiver need only verify theidentity certificates, source data, and verifiable policies that it hasnot already verified prior, thus avoiding a significant amount ofcomputation when the transmitter and receiver have similar signinghierarchies and available data. In addition if the aggregator is in facta trusted entity for the particular aggregated data being transmitted,for example if both entities are members of the same organization andthere is an organizational policy that all members of the organizationhave a certain degree of trust for each other then the receiver mayverify only that the aggregated data was indeed published by thepurported author and proceed to treat that data as authentic.

Secure Network-Portable Policy

A secure network-portable policy (SNPP) is a network-portable securedistributed document adhering to a specific format describingconditional actions in a mechanically executable way building on theinfrastructure provided by the secure network-portable aggregationprocess. The primary purpose of a SNPP is to provide the network as awhole and all users with a way to manage distributed execution of rulesets that describe resource allocation policies, incident escalationpolicies, provisioning policies, etc. With this infrastructure in placeit is possible to enable a wide variety of applications, fromincident-local provisioning (deputization) to threat-level triggereduser prioritization.

Construction

A network-portable policy contains three key elements in the dataportion of the secure network-portable document it is contained in:

-   -   Enabling criteria    -   Actions    -   A signing key

The enabling criteria describes the conditions that should be in effectfor the policy to take effect. These conditions include network-state(connectivity to a specific named device), message criteria (a messageshould be received with specific properties, for example specificauthorship and contents), and published conditions (values published ina subscription-aware network database). These conditions are eachassigned a score and a method for evaluation. For example a publishedproperty at the location “us.gov.dhs.threatlevel” may be numericallycompared to a fixed value (“yellow”) and based on that match either addor subtract from the enabling criteria score. If the enabling criteriascore exceeds the threshold embedded in the enabling criteria section ofthe document the policy is considered immediately active.

The actions section of the SNPP contains a list of actions to take whenthe policy becomes active. The actions list is broken into two groups:Enabling actions and disabling actions. The enabling and disablingaction groups are further broken down into subgroups called steps.Contained in each subgroup is a set of actions which may be executedsimultaneously, including publication of a value (for example to set“us.gov.dhs.threatlevel” to yellow) and sending of a message (to aparticular device or identity with specified payload).

The last section of the SNPP is the signing key. This signing key is thekey of the policy itself and may be used by the policy to sign messages,published conditions, and even to sign provisioning documents or furtherpolicies.

Execution

To execute a policy a device should simply walk through the enablingcriteria, evaluate each element, and verify if the resulting scoreexceeds the embedded triggering threshold. To evaluate any publishedproperties the device should first subscribe to that property in orderto be notified if its condition changes. If at any time the scoreexceeds the triggering threshold then the device should execute eachaction in each step of the enabling actions attached to the policy usingits key to secure each action as well as the policy executer's key. Oncethis is done the enabling criteria are monitored for changes. If any ofthe criteria change sufficiently to bring the score below the triggeringthreshold then the disabling actions are taken and monitoring continues.

Situational Policy

Policy Describing Deputization Criteria

At the time of an incident it is often appropriate to give escalatedauthority to on-scene first responders or other individuals. Byimplementing the correct secure network-portable policies it is possibleto allow this to be enacted largely mechanically by the networkinfrastructure and devices themselves with minimal human intervention.

The first task is to identify what additional privileges the firstresponders will need during the situation in question and what actionstheir devices should take on their behalf. In the case of an emergencyone measure that would be taken is to increase all first responders'network priority using the underlying QoS model of the network. Inaddition first responders may be granted the ability to deputize (add anendorsing signature to) civilian identity certificates, giving themsimilar communications and situational visibility rights to afull-fledged first responder but perhaps without the ability to executethe escalation policy themselves. To increase situational visibility, anaction may be added to the SNPP enabling actions list causing it tosubscribe the device's ticker application to an incident-specificmessage broadcast and to publish its location into the incident-specificavailable personnel namespace.

The second task is to specifically identify and codify the criteriaunder which the responders (in this example) may activate the policy togain additional privileges. First responders will typically needescalated privileges during an emergency. An emergency might bequantified as one of two cases: Either a local emergency or anation-wide threat alert. A local emergency may be described in terms ofthe user holding the device either being in the locale (i.e. in the cityof Washington D.C.) or within 100 miles of the border of the localewhere the emergency is taking place. This is measured by comparing thedevice's physical location (provided by GPS or another location service)with the location or region in which the emergency is described asbeing. The nation-wide threat alert may also be handled mechanically.With the DHS threat level published into the global condition namespace,this criteria might be specified by referencing the location in thenamespace (“us.gov.dhs.threatlevel”) and the required level forautomatic prioritization of first responder traffic (perhaps red). Inaddition the policy should specify that only users with identitycertificates that are marked as first responders or deputies areeligible for prioritization.

These criteria and actions may be codified into a securenetwork-portable policy document and embedded in each first responder'sdevice. See FIG. 36.

Controlled Incident Escalation

A policy may be implemented that grants additional rights to a firstresponder or other entity on the network based on situational data, suchas in the event of the presence of a local emergency or of a DHS threatalert. In such a case, conditions are published into the globalcondition namespace by a third party and read by the policy. As noted inthe secure network-portable policy definition, conditions may bepublished as an action as well as subscribed to as part of the enablingcriteria. Using this mechanism, the facility can achieve policy-basedautomated controlled incident escalation. For example, the facility maydetermine that in any single local incident in which there are more thantwenty first-responders present, the mayor, the police commissioner, thefire chief, and other local decision makers should all be notified ofsevere incidents without delay.

In this case, the facility may simply define a SNPP that publishes localalerts this and ensure that it is executed on all local firstresponders' devices. The specific implementation would state that acurrent local alert level of 1 be published to a location in the globalcondition namespace at a well known location, for example“us.states.dc.washington.alertlevel,” as soon as any registered incidenthad more than twenty on-scene responders. The only additional policythat needs to be set is one specifying that on any change of the“us.states.dc.washington.alertlevel” all members of the decisionmakers'group be sent a message and for those people to be added to that group.

With these policies in place as well as the one described in theprevious section all first responders at an incident will notify theincident commander as soon as they come on-scene (per the policy in theprevious example). Once the incident commander registers thetwenty-first on-scene responder his device will automatically publishthe value “1” to the location “us.states.dc.washington.alertlevel” asprescribed by policy and without delay or human intervention. As soon asthe alert level goes to 1 the policy indicating that the messages shouldbe sent out will be executed and the proper group will have beennotified, allowing the escalated authority to take action.

Network-Portable Service Agreements Creation

A network portable service agreement is a specialized version of asecure network-portable policy designed to allow two parties toformalize the sharing of resources in a way that can be mechanicallyevaluated, executed, and audited by the resources being shared and otherdevices operating on the network. The process by which two partiesconstruct a network-portable service agreement is similar toconstructing any other type of SNPP document:

-   -   1. Parties agree to and codify the exact terms of resource        sharing, particularly what devices will take part, what types of        service priority will be given, what type of logging will ‘lake        place, and for what term the agreement is valid.    -   2. Both parties sign the resulting service agreement document        and attach their full signature chains.    -   3. The policy is distributed to all participating devices.

Enforcement

Enforcement of systemic compliance to network-portable policy isenforced by means of logging all perceived noncompliance incidents formanual verification and resolution. If, for example, a device from oneorganization is denied access to a resource from another organizationthat under the active resource sharing policy should be available to ita noncompliance event will be created. The noncompliance event consistsof a secure network-portable document composed of the followingelements:

-   -   The nature of the noncompliance event (access denied, link        denied, etc.)    -   The identities of all parties involved (typically the device's        own identity and the remote device or service's identity)    -   Copies of applicable SNPP documents.

Once the document has been constructed it is simply transmitted to theconfigured auditing service for later resolution.

Prioritized Recovery

In order to preserve the functionality of the network for firstresponders and other emergency response personnel it is important thatduring periods of recovery from network disruptions non-responder use ofthe network be restricted so as to allow recovery and reconvergence in aminimum amount of time. There are several measures that are used toachieve this goal:

-   -   Priority reconnection    -   Priority flood    -   Priority re-registration

Priority reconnection is the mechanism by which communications needed bypriority users are brought up first before other users are serviced.This is achieved by granting each priority user a certificate denotingtheir status at provisioning time such that they may then present theiridentity when attempting to gain connectivity and be linked into thenetwork as soon as possible without waiting for any non-priority users.

Priority flood is the mechanism by which information is broadcast acrossthe entire network with maximal speed before other network informationdistribution, routing, or resource location services are ready forservice. To initiate a priority flood the sending user should (similarto priority reconnection) have additional credentials to be activeduring a time of emergency. In this case the user will be able to send asingle message which will be replicated and forwarded throughout theentire network until every device is reached. This mechanism is usefulfor ensuring that status updates, alerts, service location requests,etc. may be sent out as soon as connectivity to the network is gained.

The last mechanism used to ensure prioritized recovery is priorityservice re-registration. This mechanism ensures that as servicesre-register themselves on the network and as users attempt to reconnectto servers that priority users are given first preference for access.Prioritized re-registration works similarly to priority reconnection—asdevices attempt to connect to network resources they present theiridentity along with their priority credentials and are thus grantedimmediate access to network-available services such as messaging,conferencing, and data collection.

Live-Network Upgrade

Publishing Software & Configuration Updates

Before an update can be applied it should first be published in anaccessible and secure form. In the case of a distributed update systemthe update should be made available in at least one reliable hostinglocation (“trusted delegate”) so that it will be available for download.The trusted delegate may be located using a network service locationprotocol (perhaps a network based distributed database such as adistributed hash table) or it may be explicitly designated. In whichevercase, the notification of the update's existence should be published,and this is best done once again into a distributed database thatsupports update subscription (a method of automatic notification when aportion of the database changes).

Locating Updates

Once the update's location has been published it needs to be found byall clients needing notification for that particular update. To do this,a client needs to subscribe to the correct update feeds, and be able toinventory its installed software and configuration and map that data toa set of subscriptions to initiate. For software updates this isachieved by querying the native package management system on the device(for example the installed software list in the Windows Registry) for alist of installed software and then mapping those names into astandardized namespace for software packages, for example theSoftwareCorp CommunicationsApplication version 3.2.1 might map into theglobal namespace as“updates.softwarecorp.communicationsapplication.3.2.1.” For aconfiguration update the device should look for its provisioninginformation in a location determined by its hardware type. In the caseof an HP iPaq H5555 with serial number #123456 the path may resemble“hw.devices.hp.ipaq.h5555.123456.” In either case the value stored atthat location then resolves to a trusted delegate hosting the updatedata.

Managing Software Updates

Before installing an update the local machine should first verify thatthe update is installable under the local software update policy. Thispolicy may be constructed using the infrastructure of the SNPP documentframework, formalized as the set of circumstances under which a softwareupdate may or may not be installed taking into account factors such ascurrent user activity level, administrative authorization,intra-organizational application compatibility, and cost. This policywill also determine what priority and scheduling will be placed on theupdate's installation. Once the update has passed the policy check atransfer may be initiated.

Transferring Updates

To transfer the update in a scalable manner consideration should begiven to distributing the load of the file transfer and providing amethod for cached copies of widely distributed updates around thenetwork. While policy updates will tend to be small software updates maybe anywhere from a few hundred kilobytes to a few hundred megabytesleading to potential congestion problems. Existing swarming filetransfer techniques are sufficient for this purpose. Consideration alsoshould to be given to the balance between impact on other users on thenetwork as balanced against the urgency of update installation. The QoSsettings of the update transfer should be set based on the determinationof the update policy in order to ensure that urgent updates gettransferred with the appropriate relative priority to non-criticalupdates and other traffic on the network.

Installing Policy Updates

Policy update installation is relatively simple when built on top of thesecure network-portable policy infrastructure. The standard documentauthentication mechanism is used and the signer's credentials areverified to ensure that the policy update is authorized. Once the policyupdate has been applied software updates may be installed.

Installing Software Updates

Installation of software updates is a task best left to the nativepackage management support built into the device's host operatingsystem. In Microsoft Windows, the standard and best supported frameworkis MSI, and on that platform MSI is used. Under other operating systemsthis will vary, for example with RPM package format on Red Hat Linux orproprietary binary flash format on any number of embedded operatingsystems.

Delegated Offline Provisioning

-   -   NPSD containing set of policy, configuration, and signing data        for a device    -   Publish the document on any number of provisioning data servers        or trusted delegates    -   Provisioning data may be handled in much the same way as        software updates. See FIG. 37.

Identity-Based Auditing

Identity-based auditing is an important tool for verifying compliancewith laws and organizational policies. By providing strongauthentication and cryptographically validateable identity informationfor activity logging mechanisms it is possible to validate membercompliance with policies after the fact and offline. While it ispossible to do full policy verification at all times on every device ina distributed fashion there are cases where it can impose significantoverhead on normal operations. Because of this it is often desirable todelegate policy verification to an organizationally provided resource byflagging eligible events and transmitting them to a policy-complianceauditing system.

The first piece required is a set of criteria for what events will belogged. These criteria should be formalized and encoded as enablingcriteria on a device-local auditing policy. This policy may definecriteria such as activation when a policy verification is skippedbecause of a trust relationship with the remote end of a transaction orwhen access to a network resource is denied. Typically the criteria willspecify common but noteworthy events such as these for the purposes ofoffloading a significant amount of policy verification work whilelimiting the amount of logging data to be stored and transmitted. Whenthese events are transmitted they are encoded in the familiarnetwork-portable secure document format including

-   -   The nature of the activity    -   The identities of all parties involved (typically the device's        own identity and the remote device or service's identity)    -   Copies of applicable SNPP documents.

By including all of this data in the activity report it is possible tofully verify the policy compliance or non-compliance of the activity.The only requirement for a non-compliance to be discovered is that therebe at least one party involved in the transaction who logs and transmitsthat particular activity report. With this criteria satisfied it ispossible to discover and verify the great majority of policynoncompliance incidents in an automated fashion and in cases whereresolution or adjustment should be done manually the data is at leastmade available to the person handling the resolution.

A method is described for employing multiple frequencies to provide apush-to-talk service. In various embodiments, the method comprisesreceiving a signal in a first frequency, down-converting the receivedsignal to a digital signal, applying a business rule to thedown-converted digital signal, and, when the business rule indicatesthat the signal should be transmitted in a second frequency, causing thedown-converted digital signal to be translated to a second frequency andtransmitted in the second frequency.

A system of employing multiple frequencies to provide a push-to-talkservice is described. In various embodiments, the system comprises afirst communications network and a first peering point communicablycoupled to the first communications network that down-converts a signalreceived in a first frequency from the first network to a digitalsignal, transforms a payload of the digital signal, identifies a secondnetwork to which the signal should be transferred and provides thedigital signal to a second peering point that is communicably coupled tothe second network.

A computer-readable medium is described that has computer-executableinstructions for performing a method of employing multiple frequencies.The method comprises receiving a signal in a first frequency, convertingthe received signal to an internal representation, applying a businessrule to the converted signal, and, when the business rule indicates thatthe signal should be transmitted in a second frequency, causing theinternal representation of the signal to be translated to a secondfrequency and transmitted in the second frequency.

From the foregoing, it will be appreciated that specific embodiments ofthe invention have been described herein for purposes of illustration,but that various modifications may be made without deviating from thespirit and scope of the invention. Accordingly, the invention is notlimited except as by the appended claims.

1. A method of facilitating communications between wireless devicesusing multiple different frequencies via a peer-to-peer network thatcouples a first peering point to a second peering point, wherein thefirst peering point communicates with a plurality of first communicationdevices over a first wireless communications system using wirelesssignals of a first frequency, wherein the second peering pointcommunicates with a plurality of second communication devices over asecond wireless communications system using wireless signals of a secondfrequency, and wherein the second frequency is different from the firstfrequency, the method comprising: receiving, at the first peering point,a down-converted first digital signal with first information from thesecond peering point, wherein the first information in thedown-converted first digital signal originated from a first one of theplurality of second communication devices that was communicated to thesecond peering point; concurrently receiving, at the first peeringpoint, a down-converted second digital signal with second informationfrom the second peering point, wherein the second information in thedown-converted second digital signal originated from a second one of theplurality of second communication devices that was communicated to thesecond peering point; applying, at the first peering point, a businessrule to the down-converted first digital signal and the down-convertedsecond digital signal, wherein the business rule comprises asecure-network portable policy comprising enabling criteria and actions,wherein the enabling criteria describes conditions that are to be ineffect at an active peering point, wherein the actions indicate actionsto be taken by the active peering point when the secure-network portablepolicy becomes active, and wherein the business rule indicates that thedown-converted first digital signal has a higher priority than thedown-converted second digital signal, wherein, at a time when networkcongestion over the first communication system exceeds a threshold, themethod further comprising: translating, at the first peering point, thefirst information in the down-converted first digital signal into afirst wireless signal configured to be communicated to a first one ofthe plurality of first communication devices; communicating the firstwireless signal with the first information from the first peering pointto the first one of the plurality of first communication devices; andlater translating, at the first peering point, the second information inthe down-converted second digital signal into a second wireless signalconfigured to be communicated to a second one of the plurality of firstcommunication devices, wherein the second wireless signal with thesecond information is communicated from the first peering point to thesecond one of the plurality of first communication devices aftercommunication of the first wireless signal has completed.